1 2012-01-14 00:40:20 <CIA-100> bitcoin: Luke Dashjr signmessage_gui * rd677377706db bitcoind-personal/ (12 files in 4 dirs): Bitcoin-Qt signmessage GUI http://tinyurl.com/8a2ftt7
  2 2012-01-14 00:40:21 <CIA-100> bitcoin: Luke Dashjr coinbaser * r39414c..05c9a7 bitcoind-personal/src/ (bitcoinrpc.cpp init.cpp main.h main.cpp): (5 commits) http://tinyurl.com/3lrgdkn
  3 2012-01-14 00:42:15 <Rabbit67890-ipad> Really juke dash jr
  4 2012-01-14 00:43:00 <Rabbit67890-ipad> I always except to find evil when I see your name and I see a git commit :3
  5 2012-01-14 00:50:16 <CIA-100> bitcoin: Luke Dashjr coinbaser * r6a90f5..2e10e7 bitcoind-personal/src/ (bitcoinrpc.cpp init.cpp main.h main.cpp): (6 commits) http://tinyurl.com/3lrgdkn
  6 2012-01-14 01:10:14 <CIA-100> bitcoin: Luke Dashjr force_send * r21bcd03dd5af bitcoind-personal/src/ (bitcoinrpc.cpp main.cpp main.h noui.h wallet.cpp wallet.h): Don't automatically include fees via JSON-RPC, and (with undocumented -nosafefees option) allow forcing them to send with under the 'minimum' http://tinyurl.com/6n3q5jz
  7 2012-01-14 01:10:16 <CIA-100> bitcoin: Luke Dashjr force_send * re2ab31dafa0c bitcoind-personal/src/ (bitcoinrpc.cpp db.cpp init.cpp main.cpp main.h noui.h): Accept automatic fees up to new "maxtxfee" parameter http://tinyurl.com/7fma4rf
  8 2012-01-14 01:10:23 <CIA-100> bitcoin: Luke Dashjr force_send * r5c2fc9ede103 bitcoind-personal/src/main.cpp: Accept any transaction (fee-free or even non-standard) from myself http://tinyurl.com/6lon2ox
  9 2012-01-14 01:10:24 <CIA-100> bitcoin: Luke Dashjr force_send * r0d0622a9aa92 bitcoind-personal/src/ (bitcoinrpc.cpp wallet.cpp wallet.h): Refactor maxtxfee and -nosafefees slightly to work together http://tinyurl.com/767689p
 10 2012-01-14 01:55:55 <CIA-100> bitcoin: David Joel Schwartz rpc_keepalive * rc3ec6e260886 bitcoind-personal/src/ (bitcoinrpc.cpp net.cpp net.h): support multi-threaded RPC http://tinyurl.com/7mhrkof
 11 2012-01-14 01:55:57 <CIA-100> bitcoin: Luke Dashjr rpc_keepalive * r49ddd16dfe76 bitcoind-personal/src/bitcoinrpc.cpp: Implement ThreadSafeRPC and ThreadUnsafeRPC system to allow specific parts to be made thread-safe http://tinyurl.com/7f3u922
 12 2012-01-14 01:55:58 <CIA-100> bitcoin: David Joel Schwartz rpc_keepalive * rab345cab5e5c bitcoind-personal/src/bitcoinrpc.cpp: correct support for HTTP/1.0 and HTTP/1.1, including the proper use of keep alives http://tinyurl.com/6llb7u4
 13 2012-01-14 01:56:04 <CIA-100> bitcoin: Luke Dashjr rpc_keepalive * r7cf5b2a365a9 bitcoind-personal/src/bitcoinrpc.cpp: Allow at least CreateNewBlock (in getwork) to run in parallel with other JSON-RPC requests http://luke.dashjr.org/programs/bitcoin/w/bitcoind/luke-jr.git/commitdiff/7cf5b2a365a91e58cb27430ee4012d893726e511
 14 2012-01-14 02:15:27 <CIA-100> bitcoin: various next-test * rc9fb1d..b24e6e bitcoind-personal/ (33 files in 6 dirs): (16 commits) http://tinyurl.com/7vr93zh
 15 2012-01-14 03:11:20 <diki> are the importprivkey,dumpprivkey and so on rpc commands available in 0.5.1?
 16 2012-01-14 03:13:04 <diki> damn
 17 2012-01-14 03:13:11 <diki> it appears it might not be
 18 2012-01-14 04:00:08 <CIA-100> bitcoin: Luke Dashjr * r8006bf2246ac gentoo/net-p2p/ (3 files in 3 dirs): net-p2p/bitcoin{-qt,d}: update 9999 eligius patch http://tinyurl.com/7qzaaxt
 19 2012-01-14 10:20:00 <gribble> New news from bitcoinrss: larsr opened pull request 757 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/757>
 20 2012-01-14 13:40:33 <CIA-100> bitcoin: p2k * r11edccae1b6c ecoinpool/ (19 files in 5 dirs): Share Broker; Extended Shares Logging; Encrypt Passwords http://luke.dashjr.org/programs/bitcoin/w/ecoinpool.git/commitdiff/11edccae1b6c283ab65e2a2fce1846c184ac905a
 21 2012-01-14 13:47:35 <luke-jr> anyone else concur that Gavin's post reads "I didn't even read CHV explanations/code at all, I'm just going to troll it with nonsense" ?
 22 2012-01-14 13:52:26 <[Tycho]> luke-jr: looks like you need more supporters.
 23 2012-01-14 13:52:38 <sipa> luke-jr: where did you write about it?
 24 2012-01-14 13:55:03 <[Tycho]> Why no one is coming up with a normal solution for this problem...
 25 2012-01-14 13:55:12 <pusle> so that code was all there was to it? the CHC/CHV proposal can now be compiled and run on the testnet?
 26 2012-01-14 13:57:13 <pusle> even I are starting to agree that Luke's solution seems more generic and elegant. But I don't understand the downsides.  Less security? 1 byte larger ?
 27 2012-01-14 13:58:08 <pusle> but it's not like templates can't work either. I write vhdl for a living, and that's templates from dusk till dawn
 28 2012-01-14 13:58:31 <pusle> That's typical when you have something more abstracted/generic than what you actually wanna do. To limit the power so you don't get into problems
 29 2012-01-14 13:58:31 <sipa> there is no doubt it is more elegant
 30 2012-01-14 13:59:29 <finway> What about the 2010 July bugs?
 31 2012-01-14 13:59:36 <pusle> vhdl people coming from software development usually take a while before they can get the compiler to not go nuts ^^
 32 2012-01-14 13:59:41 <finway> anyone knows that?
 33 2012-01-14 13:59:46 <sipa> finway: which one?
 34 2012-01-14 14:00:16 <sipa> OP_CHECKSIG abuse, according to https://en.bitcoin.it/wiki/Incidents ?
 35 2012-01-14 14:00:29 <finway> Bitcoin used to validate scripts that way, but ArtForz discovered a bug in July of 2010 (the OP_RETURN bug) that allowed anybody to spend anybody else's bitcoins.  It by far Bitcoin's biggest bug and Satoshi's biggest brain-fart.
 36 2012-01-14 14:00:58 <sipa> right
 37 2012-01-14 14:01:28 <finway> I guess it's   "LSHIFT and RETURN bugs"
 38 2012-01-14 14:02:08 <finway> Nobody knows that?
 39 2012-01-14 14:03:00 <finway> at least sipa,theymos,luke didn't know that.
 40 2012-01-14 14:03:11 <finway> because you all support CHV
 41 2012-01-14 14:03:26 <sipa> yes i did, but it's slightly before my time, i didn't know the date
 42 2012-01-14 14:03:37 <pusle> "both were fixed by Bitcoin version 0.3.5."
 43 2012-01-14 14:03:39 <pusle> it says
 44 2012-01-14 14:03:41 <[Tycho]> Hmm, what's finway is doing here ?
 45 2012-01-14 14:04:00 <sipa> and only said CHV is more elegant, that doesn't mean i prefer it over the current solution
 46 2012-01-14 14:05:30 <pusle> everybody seems to agree the current solution is not viable. so either P2SH or CHV
 47 2012-01-14 14:05:46 <sipa> what do you mean by 'current solution' ?
 48 2012-01-14 14:06:01 <sipa> (i was referring to /P2SH/)
 49 2012-01-14 14:06:16 <pusle> well it's not implemented either
 50 2012-01-14 14:06:21 <sipa> sure it is
 51 2012-01-14 14:06:25 <pusle> so it's not "current"
 52 2012-01-14 14:06:29 <pusle> well, it's not live then
 53 2012-01-14 14:06:38 <sipa> it's in git head
 54 2012-01-14 14:06:45 <pusle> and Luke made code now for CHV?
 55 2012-01-14 14:06:49 <sipa> so it seems
 56 2012-01-14 14:06:51 <pusle> so they are equal in this regard too?
 57 2012-01-14 14:06:58 <pusle> okay
 58 2012-01-14 14:07:22 <pusle> CHV will take up more room?
 59 2012-01-14 14:07:25 <pusle> is it less secure?
 60 2012-01-14 14:07:45 <finway_> I'm here to see how this going
 61 2012-01-14 14:10:52 <UukGoblin> right
 62 2012-01-14 14:11:20 <UukGoblin> so in attempt to try to understand all this, I've started to document the whole process of creating, relaying and veryfying transactions - in my way
 63 2012-01-14 14:11:35 <UukGoblin> as in, in plain pseudocode, not some shitty english for dummies
 64 2012-01-14 14:11:41 <UukGoblin> https://github.com/goblin/gbl-btc-doc/blob/master/btc_txn.txt
 65 2012-01-14 14:11:54 <UukGoblin> it's still WIP, but comments (and patches!) are always welcome :-)
 66 2012-01-14 14:13:33 <sipa> UukGoblin: scriptPubKey does not contain any signature
 67 2012-01-14 14:13:42 <sipa> it only contains a script that verifies
 68 2012-01-14 14:14:05 <sipa> so it contains the pubkey and OP_CHECKSIG
 69 2012-01-14 14:14:44 <UukGoblin> sipa, cool.. thanks, let me see where I got it
 70 2012-01-14 14:16:01 <UukGoblin> ah right, I was just wrong. /me fixes
 71 2012-01-14 14:18:36 <finway> jimrandomh:I previously wrote "CODEHASHCHECK is arguably better, but only slightly". After reading Gavin's comment and the linked patch, I take that back. Introducing a non-stack interaction between scriptSig and scriptPubKey is a bad idea and a big deal, much moreso than special-case matching a script is.
 72 2012-01-14 14:18:49 <lianj> "how can dst_addr be calculated in blockexplorer without knowing Ak1_pub?" -> from the hash160
 73 2012-01-14 14:19:08 <UukGoblin> sipa, fixed, thanks :-)
 74 2012-01-14 14:19:33 <finway> jimrandomh bring up the idea of OP_EVAL,  i think it's better than CHV and roconor's what_ever_solution, he compromised.
 75 2012-01-14 14:23:04 <UukGoblin> lianj, actually, looks like the Ak1_pub is inside the Ag1::txout1, check my second commit (the fix that sipa said)
 76 2012-01-14 14:50:25 <CIA-100> bitcoin: p2k * r5173497d1277 ecoinpool/ (3 files in 3 dirs): Fix For Erlang With SSL Support http://tinyurl.com/7coa6zn
 77 2012-01-14 15:10:13 <CIA-100> bitcoin: p2k * rb50a8f16fcec ecoinpool/apps/ (2 files in 2 dirs): SSL Fix Part 2 http://tinyurl.com/74apk9p
 78 2012-01-14 15:10:14 <CIA-100> bitcoin: p2k * r746b9d1613eb ecoinpool/apps/ (2 files in 2 dirs): SSL Fix Part 3 http://tinyurl.com/876n67b
 79 2012-01-14 15:24:16 <roconnor> wait, was it gavin who sepearated the processing of scriptsig and scriptpubkey?
 80 2012-01-14 15:24:21 <roconnor> in July 2010?
 81 2012-01-14 15:27:31 <roconnor> ugh7f7f07
 82 2012-01-14 15:27:45 <roconnor> is there a way to quickly find commit 7f7f07 in github?
 83 2012-01-14 15:27:46 <sipa> disgusted?
 84 2012-01-14 15:28:03 <roconnor> sipa: only disgusted with github at the moment :D
 85 2012-01-14 15:28:57 <justmoon> roconnor: https://github.com/bitcoin/bitcoin/blob/757f0769d8360ea043f469f3a35f6ec204740446/script.cpp
 86 2012-01-14 15:29:36 <justmoon> (I happened to be looking at the history of script.cpp and saw the commit id you mentioned ;)
 87 2012-01-14 15:29:45 <sipa> roconnor: https://github.com/bitcoin/bitcoin/commit/<commitid> works, but you need 7 characters in the id
 88 2012-01-14 15:30:18 <roconnor> sipa: hah 7 characters. It is like gavin is mocking me :D
 89 2012-01-14 15:30:24 <roconnor> (by providing 6)
 90 2012-01-14 15:30:26 <sipa> no... apparently not
 91 2012-01-14 15:30:37 <sipa> you need only the *correct* 6 first ones :)
 92 2012-01-14 15:30:40 <roconnor> oh good
 93 2012-01-14 15:32:52 <roconnor> justmoon: so satoshi made this fix
 94 2012-01-14 15:33:40 <justmoon> indeed he did
 95 2012-01-14 15:33:59 <roconnor> justmoon: how do I look at the previous script.cpp?
 96 2012-01-14 15:34:27 <phantomcircuit> roconnor, do you want to know why this was done?
 97 2012-01-14 15:34:28 <phantomcircuit> :)
 98 2012-01-14 15:34:31 <sipa> roconnor: there's a link to the parent commit at the top of the page
 99 2012-01-14 15:34:32 <roconnor> phantomcircuit: I do
100 2012-01-14 15:34:58 <phantomcircuit> the input script is run first
101 2012-01-14 15:35:14 <phantomcircuit> and input script containing nothing but push 1 return would always be true
102 2012-01-14 15:35:21 <phantomcircuit> so you could spend any output
103 2012-01-14 15:35:23 <roconnor> sipa: where is this link?
104 2012-01-14 15:35:34 <phantomcircuit> thus you need to have 2 functions 1 for inputs 1 for outputs
105 2012-01-14 15:35:55 <roconnor> phantomcircuit: so back then OP_RETURN didn't always fail like it does now?
106 2012-01-14 15:36:07 <justmoon> roconnor: click on the commit comment
107 2012-01-14 15:36:18 <phantomcircuit> OP_RETURN should work in an output script
108 2012-01-14 15:37:10 <justmoon> sipa: given* (FTFY)
109 2012-01-14 15:37:26 <justmoon> also here is the full history of script.cpp until the rename: https://github.com/bitcoin/bitcoin/commits/master/script.cpp
110 2012-01-14 15:37:43 <sipa> justmoon: thanks
111 2012-01-14 15:38:16 <roconnor> wow
112 2012-01-14 15:38:17 <roconnor> look at that
113 2012-01-14 15:38:29 <roconnor> if (!EvalScript(txin.scriptSig + CScript(OP_CODESEPARATOR) + txout.scriptPubKey, txTo, nIn))
114 2012-01-14 15:38:31 <roconnor> return false;
115 2012-01-14 15:38:46 <roconnor> now wonder OP_CODESEPARATOR is currently useless
116 2012-01-14 15:39:04 <justmoon> lol, that's kinda funny
117 2012-01-14 15:39:05 <roconnor> it was made useless by this change
118 2012-01-14 15:39:12 <sipa> lol
119 2012-01-14 15:39:23 <sipa> that explains a lot, indeed
120 2012-01-14 15:39:39 <roconnor> not that I'm saying this was a bad change
121 2012-01-14 15:40:05 <roconnor> but I didn't realize the evolutionary history leading to this strange scripting system was post publication of the sources.
122 2012-01-14 15:40:32 <sipa> nice find
123 2012-01-14 15:41:06 <justmoon> early bitcoin code had much more flair
124 2012-01-14 15:41:07 <justmoon> example:
125 2012-01-14 15:41:12 <justmoon> / This is why people hate C++
126 2012-01-14 15:41:20 <justmoon> *//
127 2012-01-14 15:41:59 <justmoon> https://github.com/bitcoin/bitcoin/commit/98500d70a8cf25af4bab80526fd128ccdc36ceeb#L18L475
128 2012-01-14 15:42:15 <justmoon> imho that comment changed for the worse :P
129 2012-01-14 15:49:09 <roconnor> sipa: I think I might argue that the CodeHashVerify proposal is simply reverting some of the too severe constriction that was imposed by the OP_RETURN fix.
130 2012-01-14 15:49:40 <roconnor> is a loose sense
131 2012-01-14 15:49:44 <roconnor> *in a loose sense
132 2012-01-14 15:50:51 <helo> what degree of blockchain bloat will p2sh/chc lead to?
133 2012-01-14 15:53:16 <justmoon> helo: p2sh/chc both just move the script somewhere else, so neither one significantly changes the size of transactions, but they do move data to the inputs (which are more easily prunable)
134 2012-01-14 15:53:29 <sipa> at least in theory
135 2012-01-14 15:53:37 <justmoon> there are also less inputs at any given time than outputs
136 2012-01-14 15:53:55 <sipa> but for these long-term decisions, theory may be more important than practice
137 2012-01-14 15:54:31 <justmoon> sipa: I advocate full pruning, i.e. storage-less full nodes, but I'm too scared to post it on the forums :P
138 2012-01-14 15:55:09 <sipa> justmoon: i believe once BlueMatt's CBlockStore makes it into bitcoin, we can much more easily experiment with that
139 2012-01-14 15:55:44 <justmoon> sipa: I can already experiment with it just fine in bitcoinjs
140 2012-01-14 15:55:53 <sipa> yeah, sure
141 2012-01-14 15:56:03 <sipa> wait... storage-*less* ?
142 2012-01-14 15:56:33 <TD> hey justmoon
143 2012-01-14 15:56:45 <justmoon> nodes like that would keep the last 1000 blocks or so and block headers as well as additional info about their own transactions
144 2012-01-14 15:56:58 <justmoon> TD: wazzup!
145 2012-01-14 15:57:06 <sipa> justmoon: how can you call that a full node?
146 2012-01-14 15:57:21 <justmoon> sipa: because you don't need any other nodes in the network
147 2012-01-14 15:57:31 <sipa> it cannot verify all transactions?
148 2012-01-14 15:58:01 <justmoon> sipa: take gmaxwell's merkle tree of unspent outputs, add incremental updates block-to-block (I could talk an hours about that alone)
149 2012-01-14 15:58:31 <justmoon> a node submitting a transaction needs to supply the transaction it's spending from, it's merkle branch and the merkle diff for the output
150 2012-01-14 15:58:34 <sipa> ok, so it's last 1000 blocks + db of unspent txouts
151 2012-01-14 15:58:37 <sipa> sure, in that case
152 2012-01-14 15:58:40 <justmoon> nonono
153 2012-01-14 15:58:43 <justmoon> no db of unspent txouts
154 2012-01-14 15:59:06 <sipa> ok, that's also a possibility
155 2012-01-14 15:59:25 <justmoon> yes, you trade storage for network traffic
156 2012-01-14 15:59:29 <justmoon> usually a horrible idea
157 2012-01-14 15:59:30 <sipa> but now you've moved part of the block storage to the transaction creators
158 2012-01-14 15:59:36 <justmoon> true
159 2012-01-14 15:59:45 <sipa> not sure i like that :)
160 2012-01-14 16:00:11 <justmoon> well, there are reasons why I haven't posted it
161 2012-01-14 16:00:18 <justmoon> the network traffic is the bigger argument
162 2012-01-14 16:00:19 <sipa> haha
163 2012-01-14 16:00:25 <TD> roconnor: where is that?
164 2012-01-14 16:00:34 <justmoon> basically I came up with it because I wanted to remove the block size limit
165 2012-01-14 16:00:38 <sipa> TD: the code he copy-pasted?
166 2012-01-14 16:00:53 <justmoon> in this mode, the expensive part is transferring the blocks
167 2012-01-14 16:01:07 <luke-jr> pusle: the patch for CHV I wrote *should* work, but I haven't tested it, and it doesn't change any of the client-specific stuff (ie, 3-addresses)
168 2012-01-14 16:01:14 <justmoon> and it is possible to force most of the cost on the miner who initially publishes the block
169 2012-01-14 16:01:18 <TD> oh, i see
170 2012-01-14 16:01:19 <TD> https://github.com/bitcoin/bitcoin/commit/757f0769d8360ea043f469f3a35f6ec204740446
171 2012-01-14 16:01:24 <justmoon> whereas the storage costs are mostly externalities
172 2012-01-14 16:01:24 <TD> reverted makefile.unix wx-config -- version 0.3.6
173 2012-01-14 16:01:28 <TD> what a totally useless commit message
174 2012-01-14 16:01:47 <luke-jr> I guess I need to elaborate on Gavin's post&
175 2012-01-14 16:03:30 <roconnor> Oh man, if only OP_CODESEPARATOR had been disabled in that commit, reimplementing bitcoin would be so much easier.
176 2012-01-14 16:03:33 <justmoon> TD: I originally thought the commit message was due to a problem with the subversion import, but the original svn commit has the same message: http://bitcoin.svn.sourceforge.net/viewvc/bitcoin?view=revision&revision=119
177 2012-01-14 16:03:47 <roconnor> I have to write so much code just to support that useless operation.
178 2012-01-14 16:04:35 <TD> well, i guess that answers my question about what it was for, given that it's useless
179 2012-01-14 16:04:40 <TD> evolutionary dead end, indeed
180 2012-01-14 16:05:09 <TD> it's surprising that such core parts of the protocol were changing even in 2010
181 2012-01-14 16:05:19 <sipa> i think we can safely declare OP_CODESEPARATOR dead now :)
182 2012-01-14 16:05:57 <TD> the diff is really hard to read
183 2012-01-14 16:07:21 <k9quaint> while you are reimplementing btc, can you do one for me in Lisp too?
184 2012-01-14 16:08:06 <justmoon> if you do one in lisp, can you port it to elisp? I want to have a bitcoin client in my editor
185 2012-01-14 16:08:20 <justmoon> TD: query
186 2012-01-14 16:08:26 <TD> READY>
187 2012-01-14 16:08:44 <justmoon> ?
188 2012-01-14 16:09:04 <TD> you want to query me ?
189 2012-01-14 16:09:13 <k9quaint> TD: repl
190 2012-01-14 16:09:16 <justmoon> lol
191 2012-01-14 16:09:24 <justmoon> I send you a private IRC message
192 2012-01-14 16:09:27 <TD> oh, sorry
193 2012-01-14 16:09:28 <justmoon> also called a query
194 2012-01-14 16:09:30 <justmoon> :P
195 2012-01-14 16:10:23 <CIA-100> libbitcoin: Kamil Domanski * r973c1718f8aa /.gitignore: added netbeans project dir to .gitignore http://luke.dashjr.org/programs/bitcoin/w/libbitcoin.git/commitdiff/973c1718f8aa3e55b5b7771d1b9c80dc9c7cefbb
196 2012-01-14 16:10:24 <CIA-100> libbitcoin: Kamil Domanski * r316553a66dcc /.gitignore: libbitcoin.pc is a generated file, added to .gitignore http://tinyurl.com/6wymjz2
197 2012-01-14 16:10:26 <CIA-100> libbitcoin: Kamil Domanski * reb50ebf22469 /src/network/handshake.cpp: Merge branch 'master' of gitorious.org:libbitcoin/libbitcoin http://tinyurl.com/7uevdzj
198 2012-01-14 16:12:53 <[Tycho]> Hmm, core developers are fighting, is this the end of bitcoin ? :)
199 2012-01-14 16:14:25 <luke-jr> sipa: CHV puts it to good use
200 2012-01-14 16:17:22 <luke-jr> helo: CHV only reduces bloat.
201 2012-01-14 16:21:53 <gruez> just wondering
202 2012-01-14 16:22:03 <gruez> how much bitcoin users are there?
203 2012-01-14 16:23:55 <marf_away> hard to say
204 2012-01-14 16:24:01 <marf_away> i guess around 100k
205 2012-01-14 16:24:46 <gruez> seriously?
206 2012-01-14 16:24:55 <gruez> there aren't even that many nodes
207 2012-01-14 16:25:07 <marf_away> not every user has a client installed
208 2012-01-14 16:25:16 <marf_away> many use onliewallets
209 2012-01-14 16:25:23 <marf_away> or client is just off
210 2012-01-14 16:25:41 <Joric> there were only about 60k bitcoin nodes noticed since beginning of time
211 2012-01-14 16:25:47 <gmaxwell> marf_away's number doesn't sound insane to me, though it might be lower.
212 2012-01-14 16:26:02 <TD> i think when mtgox database leaked, it had ~50k accounts in it, or something
213 2012-01-14 16:26:08 <gmaxwell> Joric: non-listening clients won't rumor their addresses IIRC.
214 2012-01-14 16:26:18 <TD> i suspect quite a few bitcoin "users" just have accounts at pools and exchanges
215 2012-01-14 16:26:23 <TD> and never use non-web software at all
216 2012-01-14 16:27:18 <sipa> depending on your definition of "user", some may only be running a miner
217 2012-01-14 16:27:50 <gruez> anyone notice, that it's really profitable to mine right now?
218 2012-01-14 16:27:55 <sipa> Joric: my crawler has seen 400k unique addresses up to now (some of which may be fake or bugs)
219 2012-01-14 16:28:07 <gruez> sipa: could be dynamic ip
220 2012-01-14 16:28:13 <Joric> oh
221 2012-01-14 16:28:15 <sipa> gruez: yes, that too
222 2012-01-14 16:28:26 <Joric> i've watched this http://bitcoinstatus.rowit.co.uk
223 2012-01-14 16:30:10 <TD> probably  few hundred thousand people have tried it
224 2012-01-14 16:30:14 <TD> and got bored waiting for the chain to download :)
225 2012-01-14 16:30:30 <Joric> can't blame them
226 2012-01-14 16:31:59 <edcba> i totally don't understand chart labels
227 2012-01-14 16:33:03 <gruez> what's the point of op_eval?
228 2012-01-14 16:33:13 <gruez> seems to be pissing some people off
229 2012-01-14 16:36:02 <roconnor> gruez: to shorten complex bitcoin addresses
230 2012-01-14 16:36:37 <gmaxwell> gruez: please actually read the discussion in the thread that made you ask that.
231 2012-01-14 16:37:06 <roconnor> I think reading threads is a poor way to understand what is going on.
232 2012-01-14 16:37:17 <edcba> shorten or weaken ?
233 2012-01-14 16:37:27 <sipa> shorten
234 2012-01-14 16:38:08 <edcba> is that sole purpose ?
235 2012-01-14 16:38:12 <gmaxwell> No.
236 2012-01-14 16:38:33 <gmaxwell> But you should read instead of disrespecting people's time by asking what you could just read about.
237 2012-01-14 16:38:36 <gruez> i read something to do with 2 factor authentication?
238 2012-01-14 16:38:43 <gruez> so people cant steal your wallet?
239 2012-01-14 16:39:40 <gmaxwell> gruez: Yes, roconnor would point out that you could also do that with addresses which are (hundreds of bytes) long, op_eval/p2sh make those addresses the same length as current ones.
240 2012-01-14 16:40:44 <gmaxwell> But thats not the only improvement they make in that cases: They move related TXN fees to the recipent who decided to have a complicated wallet protection scheme, and they move the blockchain storage from the output (which may never be prunable) to the input which always is.
241 2012-01-14 16:41:14 <gmaxwell> So p2sh/op_eval reduce the spam attack liability of accepting more complicated transactions.
242 2012-01-14 16:44:09 <pusle> you mean p2sh/chv? seems hardly anyone want op_eval
243 2012-01-14 16:44:32 <sipa> op_eval allowed for much more than whan people seem to want
244 2012-01-14 16:44:45 <k9quaint> gmaxwell: is there anyplace I can read about bitcoin?
245 2012-01-14 16:45:04 <egecko> start with the white paper shatoshi wrote.
246 2012-01-14 16:45:17 <edcba> ok sorry to make ppl time losses but don't feel obligated to answer ;)
247 2012-01-14 16:45:18 <gmaxwell> :) useful answers to troll questions warms my heart.
248 2012-01-14 16:45:26 <k9quaint> gmaxwell: I am gnawing my mouse ;P
249 2012-01-14 16:46:00 <egecko> and really if you're on -dev, then perhaps you could read the source code :)
250 2012-01-14 16:46:29 <k9quaint> I was gonna play off "shat"oshi, but I am better than that
251 2012-01-14 16:46:57 <[Tycho]> Hmm, number of nodes is declining ?
252 2012-01-14 16:47:21 <k9quaint> I think that is a reflection of the maturation of web services around bitcoin
253 2012-01-14 16:48:23 <gmaxwell> [Tycho]: at least as measure by rumored addresses, IRC connections, or connectable listeners.
254 2012-01-14 16:49:20 <[Tycho]> People are using web-services, what a shame.
255 2012-01-14 16:49:53 <gmaxwell> [Tycho]: it takes about 20 hours to sync up a client now on randomly selected typical-user-hardware.
256 2012-01-14 16:49:54 <edcba> what i don't understand is many(?) ppl don't like the scripting system and propositions like op_eval just 'enhance' it
257 2012-01-14 16:50:18 <edcba> instead of using some new OP for the sole purpose of reducing addresses
258 2012-01-14 16:50:47 <luke-jr> pusle: I'd prefer OP_EVAL over BIP 16
259 2012-01-14 16:50:49 <gruez> gmaxwell: does blockchain sync faster if you have NAT open?
260 2012-01-14 16:50:56 <gmaxwell> gruez: no.
261 2012-01-14 16:51:10 <gmaxwell> gruez: the time is related to validating the history, not network traffic.
262 2012-01-14 16:51:58 <pusle> luke: really? a full blown programming language embedded in bitcoin? that's whole universe of cans full of worms to find :x
263 2012-01-14 16:52:41 <edcba> and i doubt we really need a new bitcoin security disaster
264 2012-01-14 16:52:46 <gmaxwell> pusle: he wants OP_x86asm
265 2012-01-14 16:53:00 <edcba> even if precedents were user based :)
266 2012-01-14 16:53:13 <[Tycho]> Actually I would prefer using recipient addresses in the sending script for multisig TXes :)
267 2012-01-14 16:53:15 <pusle> why not 6502? :P
268 2012-01-14 16:53:25 <pusle> or! my belowed motorola 68000, best assembly ever! :D
269 2012-01-14 16:53:55 <pusle> lets take that and make it a full 2addy edition. That would roxxx0rez ;)
270 2012-01-14 16:53:57 <egecko> can we get a bitcoin client for the commodore64 too? i'm sure there's at least 1 person who wants that.
271 2012-01-14 16:53:59 <edcba> we need to go more enterprisy we'll just put some java interpreter
272 2012-01-14 16:54:06 <edcba> (or java compatible)
273 2012-01-14 16:54:12 <egecko> java sucks
274 2012-01-14 16:59:50 <luke-jr> pusle: there is ALREADY a full blown programming language in Bitcoin
275 2012-01-14 16:59:58 <gruez> ?
276 2012-01-14 17:00:09 <gruez> orly?
277 2012-01-14 17:00:11 <luke-jr> gmaxwell: OP_MIPS actually
278 2012-01-14 17:00:15 <pusle> O_o
279 2012-01-14 17:00:26 <luke-jr> pusle: Bitcoin as-is, is designed around a scripting language.
280 2012-01-14 17:01:28 <Eliel> luke-jr: can it be called full blown if it's not turing complete?
281 2012-01-14 17:01:31 <pusle> luke: can you make a branch and implement your proposal 100% ?  then other developers can see what you really mean and evaluate it against p2sh
282 2012-01-14 17:02:06 <pusle> seems there are much misunderstandings in the forums, and your proposal is evolving too I guess
283 2012-01-14 17:02:32 <Eliel> pusle: OP_EVAL spec is already out there.
284 2012-01-14 17:03:28 <pusle> and almost nobody wants it. So we now have p2sh and maybe chv ?
285 2012-01-14 17:05:13 <Eliel> OP_EVAL makes the script language too full blown :)
286 2012-01-14 17:05:24 <luke-jr> pusle: my branch includes the minimal protocol changes
287 2012-01-14 17:05:57 <pusle> so anyone can now compile and test it? it's good to go?
288 2012-01-14 17:06:49 <luke-jr> I would suggest making a few minor changes before deploying it.
289 2012-01-14 17:07:01 <luke-jr> ie, making the hash type configurable
290 2012-01-14 17:07:52 <pusle> then it should be easy for the software gurus here to validate your claims and post a definitive answer to this thread: https://bitcointalk.org/index.php?topic=58579.40
291 2012-01-14 17:08:42 <roconnor> what does stack.erase(stack.begin()); do?
292 2012-01-14 17:09:56 <pusle> Get your shit together or I'll email Dan Kaminsky soon! :D
293 2012-01-14 17:11:27 <luke-jr> roconnor: it deletes the first item on the stack
294 2012-01-14 17:13:20 <luke-jr> roconnor: basically, I'm just throwing the extra data on the head of the stack to avoid adding a new parameter to the function. ideally, it should be refactored to use some kind of "interpretor state" class IMO
295 2012-01-14 17:13:31 <roconnor> yep
296 2012-01-14 17:13:34 <roconnor> I understand now
297 2012-01-14 17:14:15 <luke-jr> (in the meantime, this hack is simple, should work fine, and most importantly doesn't affect the protocol)
298 2012-01-14 17:15:49 <roconnor> luke-jr: I was confused at first since your code also has P2SH implemented.
299 2012-01-14 17:15:59 <luke-jr> ah
300 2012-01-14 17:16:06 <luke-jr> ripping out BIP 16 really *is* a pain :/
301 2012-01-14 17:16:28 <sipa> you are still changing the semantics of OP_NOP; that's cleaner than a magic script, but it is essentially the same: making old valid things invalid
302 2012-01-14 17:17:44 <roconnor> luke-jr's OP_NOP change does satify the sipa NOP extension principle IIUC
303 2012-01-14 17:17:50 <justmoon> sipa: imho, a preprocessor (p2sh) is clean and an opcode that shuffles code around is what's a hack
304 2012-01-14 17:18:00 <justmoon> sipa: see my post for the full argument: https://bitcointalk.org/index.php?topic=56969.msg691560#msg691560
305 2012-01-14 17:19:24 <pusle> so it's almost coke vs pepsi?
306 2012-01-14 17:19:33 <luke-jr> roconnor: ?
307 2012-01-14 17:20:23 <luke-jr> justmoon: there's no code shuffling going on
308 2012-01-14 17:20:32 <roconnor> justmoon says ``For example, to implement OP_CODEHASHCHECK we would need to change EvalScript to know about where scriptSig ends and scriptPubKey begins. The scripting language is not meant to be aware of the block chain, it is meant to be a simple, stack-based language.
309 2012-01-14 17:20:36 <sipa> roconnor: it does, i never claimed otherwise
310 2012-01-14 17:20:37 <roconnor> justmoon: I don't think this is true.
311 2012-01-14 17:20:45 <luke-jr> justmoon: and BIP 16 doesn't use preprocessor stuff of any kind
312 2012-01-14 17:20:50 <roconnor> sipa: ya sorry, I misread your comment.
313 2012-01-14 17:20:52 <luke-jr> C doesn't act on its own
314 2012-01-14 17:21:48 <justmoon> roconnor: luke's implementation does it differently, but my point was that the script interpreter would have to be aware that is executing two scripts
315 2012-01-14 17:22:02 <justmoon> roconnor: it's reflected in the vchLastScript hack
316 2012-01-14 17:22:22 <roconnor> justmoon: no more than it already is.
317 2012-01-14 17:22:52 <roconnor> the OP_RETURN fix radically changed the interpreter to run in two phases
318 2012-01-14 17:23:00 <justmoon> roconnor: then whence cometh the vchLastScript?
319 2012-01-14 17:23:02 <roconnor> who share information through the main stack.
320 2012-01-14 17:23:17 <justmoon> exactly
321 2012-01-14 17:23:24 <justmoon> we'd have to essentially reverse that
322 2012-01-14 17:23:25 <roconnor> the CHV adds another state variable to this communication channel
323 2012-01-14 17:23:33 <justmoon> to some extent at least
324 2012-01-14 17:23:50 <justmoon> yeah, I have no problem with that
325 2012-01-14 17:23:53 <roconnor> which is currently hacked to sit on top of the main stack in the proposed implementation.
326 2012-01-14 17:23:56 <justmoon> I just think it's less clean than p2sh
327 2012-01-14 17:24:33 <pusle> so how about security?  P2SH vs CHV
328 2012-01-14 17:25:07 <pusle> which one has the most states and "dark corners"
329 2012-01-14 17:25:35 <justmoon> pusle: CHV changes the most complex function in bitcoin, so p2sh wins that one
330 2012-01-14 17:25:41 <luke-jr> justmoon: not at all
331 2012-01-14 17:25:46 <luke-jr> CHV is simple and straightforward
332 2012-01-14 17:25:55 <justmoon> luke-jr: no argument from me
333 2012-01-14 17:25:59 <luke-jr> P2SH changes the whole process significantly
334 2012-01-14 17:26:06 <justmoon> that I disagree with
335 2012-01-14 17:26:10 <Eliel> can someone outline the most significant differences between p2sh and chv?
336 2012-01-14 17:26:11 <luke-jr> ugh, stop calling it p2sh& all these are p2sh
337 2012-01-14 17:26:26 <pusle> but if P2SH is more restricted and less powerful, then it should also be more safe?
338 2012-01-14 17:26:37 <luke-jr> Eliel: I'm not sure there's anything in common
339 2012-01-14 17:26:44 <luke-jr> pusle: it's not
340 2012-01-14 17:27:06 <luke-jr> pusle: CHV just adds a simple new opcode; BIP 16 adds a whole new program flow
341 2012-01-14 17:27:19 <roconnor> luke-jr: P2SH basically only allows pay to signature hash; while CHV allows for that plus some other stuff.  The names are resonably appropriate.
342 2012-01-14 17:27:52 <luke-jr> pay-to-script-hash describes OP_EVAL, BIP 16, and CHV
343 2012-01-14 17:28:17 <luke-jr> Eliel: BIP 16 evaluates code from the stack, like OP_EVAL
344 2012-01-14 17:28:25 <luke-jr> Eliel: CHV just checks code that has already been executed
345 2012-01-14 17:28:31 <luke-jr> (the normal way)
346 2012-01-14 17:29:21 <pusle> roconnor? Luke is correct on all counts?
347 2012-01-14 17:29:49 <roconnor> pusle: what is more restricted and what is more powerful is somewhat a matter of opinion
348 2012-01-14 17:30:11 <pusle> ok
349 2012-01-14 17:30:41 <pusle> but Gavins claims should be possible to confirm or refute based on the code by Luke
350 2012-01-14 17:31:09 <Eliel> luke-jr: BIP 16 isn't an actual opcode so I'm not sure if you could really say that it executes code from stack.
351 2012-01-14 17:31:14 <roconnor> I can review gavin's claims now that I think I understand luke-jr's code
352 2012-01-14 17:31:28 <luke-jr> pusle: indeed, I can't believe Gavin actually read my code&
353 2012-01-14 17:31:32 <pusle> https://bitcointalk.org/index.php?topic=58579.40
354 2012-01-14 17:31:36 <luke-jr> Eliel: it does, though.
355 2012-01-14 17:31:36 <pusle> roconnor: please do :)
356 2012-01-14 17:32:11 <Eliel> luke-jr: and even if it does, why would that be bad, exactly?
357 2012-01-14 17:32:14 <roconnor> pusle: thread comment #46?
358 2012-01-14 17:32:32 <luke-jr> Eliel: iff the scriptPubKey matches the magic template, then instead of executing scriptPubKey it does its own validation including executing the top stack item left by scriptSig
359 2012-01-14 17:32:38 <pusle> roconnor: yes and see #55
360 2012-01-14 17:33:41 <roconnor> pusle: okay; scriptSig and scriptPubKey are not concatinated;  Gavin's comment appears to be based on either puik misrepresentation of luke-jr's proposal or a earlier version of luke-jr's proposal.
361 2012-01-14 17:34:19 <luke-jr> I've only implemented CHV once, FWIW.
362 2012-01-14 17:34:21 <roconnor> pusle: I don't know which of BIP 16 and CHV's implemenations are more likely to have a subtle bug.
363 2012-01-14 17:35:13 <pusle> roconnor: please make a post with your opinions and perhaps include the git link again
364 2012-01-14 17:35:29 <roconnor> pusle: I don't think I will do that.
365 2012-01-14 17:35:36 <pusle> lol, why not ? :P
366 2012-01-14 17:36:16 <roconnor> then I become responsible for whatever the fallout is
367 2012-01-14 17:36:26 <luke-jr> >_<
368 2012-01-14 17:36:39 <luke-jr> roconnor: isn't the good of Bitcoin worth it? :P
369 2012-01-14 17:37:00 <pusle> skilled people have to get into this, or it's just Gavin vs Luke. Both seems to have some ego issues...
370 2012-01-14 17:37:24 <roconnor> pusle: only a few weeks ago it was roconnor vs Gavin, and both seemed to have some ego issues
371 2012-01-14 17:37:29 <luke-jr> lol
372 2012-01-14 17:37:31 <pusle> hehe
373 2012-01-14 17:37:42 <luke-jr> I don't really care what happens, so long as it isn't BIP 16 :P
374 2012-01-14 17:37:43 <pusle> remember, most people who care about bitcoin are like me
375 2012-01-14 17:37:51 <pusle> and we really need all of you to give your views
376 2012-01-14 17:38:02 <pusle> you, the guys with the skills!
377 2012-01-14 17:38:05 <pusle> luke
378 2012-01-14 17:38:07 <pusle> gavin
379 2012-01-14 17:38:10 <pusle> roconnor
380 2012-01-14 17:38:14 <pusle> gmaxwell
381 2012-01-14 17:38:15 <pusle> etc
382 2012-01-14 17:38:16 <pusle> etc
383 2012-01-14 17:38:19 <pusle> the more the better
384 2012-01-14 17:38:20 <roconnor> sipa
385 2012-01-14 17:38:22 <pusle> yes
386 2012-01-14 17:38:23 <roconnor> justmoon, TD
387 2012-01-14 17:38:34 <pusle> right, MOAR! :)
388 2012-01-14 17:38:44 <roconnor> what Does Artzfort (sp?) think?
389 2012-01-14 17:38:45 <justmoon> yeah, ping everybody you trolls -_-
390 2012-01-14 17:38:46 <pusle> if I had the skills I would too
391 2012-01-14 17:38:53 <roconnor> he is the best at cracking bitcoin.
392 2012-01-14 17:38:56 <pusle> but since I don't I have to appeal to you out there ...
393 2012-01-14 17:39:20 <luke-jr> mtve!
394 2012-01-14 17:39:46 <luke-jr> I do think ArtForz should be asked, actually
395 2012-01-14 17:39:55 <luke-jr> after a proper explanation of everything
396 2012-01-14 17:40:00 <luke-jr> where is he?
397 2012-01-14 17:40:01 <luke-jr> :p
398 2012-01-14 17:40:12 <pusle> yes, so who are his buddy on here?
399 2012-01-14 17:40:43 <roconnor> pusle: anyhow, my opinion is that both P2SH and CHV are about equal, and both are somewhat worse than doing nothing, and both are infinitely better than OP_EVAL.
400 2012-01-14 17:40:48 <gribble> ArtForz was last seen in #bitcoin-dev 30 weeks, 3 days, 20 hours, 24 minutes, and 32 seconds ago: <ArtForz> eternal beta. hah, satoshi is secretly a google employee!
401 2012-01-14 17:40:48 <justmoon> ;;seen ArtForz
402 2012-01-14 17:41:01 <justmoon> roconnor: agreed
403 2012-01-14 17:41:12 <pusle> okay, so it is coke vs pepsi
404 2012-01-14 17:41:12 <roconnor> pusle: more importantly I think changing the core protocol is being pushed too fast
405 2012-01-14 17:41:13 <luke-jr> roconnor: you seriously think we don't need *some* kind of P2SH (generic)
406 2012-01-14 17:41:20 <pusle> I do know some people really hate pepsi
407 2012-01-14 17:41:24 <pusle> I guess Luke? ;)
408 2012-01-14 17:41:25 <pusle> hehe
409 2012-01-14 17:41:28 <luke-jr> I hate Pepsi and Coke.
410 2012-01-14 17:41:29 <justmoon> I would like to see a more mature implementation of CHV
411 2012-01-14 17:41:32 <luke-jr> But I hate Coke more.
412 2012-01-14 17:41:49 <luke-jr> justmoon: yeah, I definitely agree more time would make things better
413 2012-01-14 17:42:01 <luke-jr> I only drafted CHV because BIP 16 is so bad
414 2012-01-14 17:42:21 <pusle> most seems to think the difference is small
415 2012-01-14 17:42:23 <justmoon> how would the CHECKSIG counting look with CHV - no change needed correct?
416 2012-01-14 17:42:42 <pusle> Luke: You have to make a proper implementation so people can compile and run it
417 2012-01-14 17:42:44 <luke-jr> justmoon: CHV doesn't change any behaviours except OP_NOP1
418 2012-01-14 17:42:54 <justmoon> so that would be Pro: Less of a change and Con: We can't do the more precise CHECKSIG counting that BIP 16 allows
419 2012-01-14 17:42:55 <pusle> only then will CHV be a contender against P2SH
420 2012-01-14 17:43:03 <luke-jr> pusle: the problem is, BIP 16 code is in the way of user-facing changes
421 2012-01-14 17:43:16 <luke-jr> pusle: and Gavin's made it very difficult to remove BIP 16
422 2012-01-14 17:43:41 <luke-jr> justmoon: hmm? CHV doesn't require *any* change to CHECKSIG counting
423 2012-01-14 17:43:42 <pusle> If BIP16 is so bad, I'm sure you have the motivation to make a good CHV implementation :)
424 2012-01-14 17:43:58 <luke-jr> pusle: I could do so very easily, if BIP 16 weren't in the way
425 2012-01-14 17:44:29 <pusle> from the limited skills I have , I would say I am actually leaning towards CHV as the cleanest...but both are hacky according to 3rd party people
426 2012-01-14 17:44:31 <justmoon> luke-jr: yes, but BIP 16 changes checksig counting for the better - it looks at the last opcode before the CHECKMULTISIG and if it's a OP_1 to OP_16 it uses that instead of the 20 upper bound
427 2012-01-14 17:44:53 <pusle> luke: can't you revert and start from before BIP16 was added?
428 2012-01-14 17:45:12 <luke-jr> justmoon: wait, BIP 16 is actually changing the rules for the evaluated code?
429 2012-01-14 17:45:13 <CIA-100> bitcoin: Luke Dashjr signmessage_gui * r21df4531579b bitcoind-personal/ (12 files in 4 dirs): Bitcoin-Qt signmessage GUI http://tinyurl.com/7ay4omw
430 2012-01-14 17:45:32 <luke-jr> pusle: no, because of how Gavin did it
431 2012-01-14 17:45:33 <justmoon> luke-jr: only the checksig counting anti-DoS rules
432 2012-01-14 17:45:41 <luke-jr> pusle: it's not a simple revert
433 2012-01-14 17:45:41 <pusle> O_o
434 2012-01-14 17:46:05 <luke-jr> justmoon: in any case, miners could enforce stricter counting
435 2012-01-14 17:46:18 <justmoon> luke-jr: on their own blocks you mean?
436 2012-01-14 17:46:22 <luke-jr> justmoon: yes
437 2012-01-14 17:46:41 <sipa> the actual Pro: in general of BIP16 vs. CHV is a) soft-verification by old nodes (which may be a non-issue) and b) the ability to do upgrades to the scripting language
438 2012-01-14 17:46:57 <sipa> so far, b) is only used to have a more strict CHECKSIG checking, i believe
439 2012-01-14 17:47:04 <justmoon> sipa: yes
440 2012-01-14 17:47:04 <luke-jr> sipa: no, we lose t he ability to do upgrades if we deploy BIP16 now
441 2012-01-14 17:47:21 <luke-jr> once BIP16 is deployed, the rules are fixed
442 2012-01-14 17:47:41 <justmoon> well the rules are already fixed
443 2012-01-14 17:47:51 <justmoon> BIP16 represents a one-time rule upgrade possibility
444 2012-01-14 17:48:01 <luke-jr> and it's not being used in any significant way
445 2012-01-14 17:48:06 <justmoon> yes
446 2012-01-14 17:48:20 <justmoon> well, semisignificant I guess
447 2012-01-14 17:49:01 <luke-jr> technically speaking, miners *could* be stricter on CHECKSIG counts
448 2012-01-14 17:49:08 <pusle> I think next time there is a change, it will be even more hard to reach consensus so we better get this one right :&
449 2012-01-14 17:49:16 <sipa> luke-jr: for accepting to their memory pools, sure
450 2012-01-14 17:49:21 <sipa> luke-jr: but not when verifying blocks
451 2012-01-14 17:49:39 <luke-jr> sipa: for verifying blocks, it has the same effect as adding BIP16 or CHV
452 2012-01-14 17:49:52 <luke-jr> sipa: that is, so long as a supermajority agree, it's safe
453 2012-01-14 17:50:02 <justmoon> luke-jr: no, bip16's rules are for block verification (MAX_BLOCK_SIGOPS limit)
454 2012-01-14 17:50:11 <roconnor> hmm, BIP 0016 would be a good opportinuty to make some simplifications; like making OP_CODESEPARATOR illegal in the deserialized code.
455 2012-01-14 17:50:19 <sipa> roconnor++
456 2012-01-14 17:50:28 <luke-jr> roconnor: better to just Reject BIP 16 and do something sane
457 2012-01-14 17:50:33 <justmoon> lol, that might actually be an argument against BIP 16
458 2012-01-14 17:50:34 <roconnor> this proposal should be delayed
459 2012-01-14 17:50:45 <justmoon> now everyone will come forward with their wish list for a script change
460 2012-01-14 17:50:51 <sipa> justmoon: haha
461 2012-01-14 17:50:52 <justmoon> (as in verification rules changes)
462 2012-01-14 17:51:02 <roconnor> justmoon: it is a golden opportunity for that
463 2012-01-14 17:51:10 <sipa> let's just create an entirely new and sane scripting language, and use that in bip 16!
464 2012-01-14 17:51:11 <luke-jr> roconnor: I think Gavin's made it clear he won't tolerate much delays, unfortunately. :<
465 2012-01-14 17:51:15 <justmoon> roconnor: not if we take into account that this is supposed to land in a few weeks
466 2012-01-14 17:51:29 <roconnor> sipa:  it is tempting
467 2012-01-14 17:52:07 <roconnor> justmoon: well, I never though doing this in a few weeks was a good idea :D
468 2012-01-14 17:52:10 <roconnor> *thought
469 2012-01-14 17:52:23 <luke-jr> if anyone has a solution to the trojan problem without any kind of P2SH, that would buy us time&
470 2012-01-14 17:52:33 <luke-jr> AIUI, that's Gavin's main rush
471 2012-01-14 17:52:33 <pusle> Luke: you have 1 month to make the CHV code mean and lean. You GO girl! ^-^
472 2012-01-14 17:53:04 <sipa> on the other hand, roconnor, thanks to you, we've talked and discussed and invented more the past few weeks about it than all time before than :)
473 2012-01-14 17:53:14 <sipa> *that
474 2012-01-14 17:53:19 <justmoon> word.
475 2012-01-14 17:53:35 <sipa> ").correctGrammar();
476 2012-01-14 17:53:49 <Eliel> luke-jr: there was someone working on doing multisig with ecdsa magic. Would work without any code changes.
477 2012-01-14 17:53:55 <Eliel> in bitcoin core that is
478 2012-01-14 17:54:14 <gmaxwell> luke-jr: the 'main rush' is that this is all step zero. Realistically you're looking at a solid 6 months to a year _AFTER_ a p2sh solution is deployed before people are using it at any scale.
479 2012-01-14 17:54:26 <justmoon> sipa: Syntax Error in line 1, char 1, unmatched "
480 2012-01-14 17:54:29 <luke-jr> Eliel: got a link?
481 2012-01-14 17:54:43 <sipa> justmoon: i'm sure i once typed a dangling " here before :)
482 2012-01-14 17:54:53 <Eliel> I'll see if I can find it again.
483 2012-01-14 17:54:55 <luke-jr> gmaxwell: I know that, but if the primary motivation for P2SH goes away, we can buy time to get it done and tested well
484 2012-01-14 17:54:58 <justmoon> :P
485 2012-01-14 17:55:01 <gmaxwell> luke-jr: since people who process payments will need to upgrade and change their software to get 3-address support.
486 2012-01-14 17:55:27 <luke-jr> whether we rush or not, BIP16 is not the answer.
487 2012-01-14 17:55:54 <sipa> one question i have now is that in both the case of /P2SH/ (can we please call it magicscript or bip16 instead?) and CHV, is how *will* we do a script language upgrade afterwards
488 2012-01-14 17:56:28 <justmoon> sipa: we don't, scripting language upgrade will be a forking change
489 2012-01-14 17:56:29 <roconnor> sipa: I'll try calling it BIP16 from now on
490 2012-01-14 17:56:30 <luke-jr> sipa: the only way to do a script language upgrade with both BIP16 and CHV, is by adding OP_EVAL of some form
491 2012-01-14 17:56:33 <gmaxwell> sipa: add a NOP at the end of the magicscript.
492 2012-01-14 17:56:40 <luke-jr> or fork the block chain
493 2012-01-14 17:56:43 <justmoon> yeah I guess OP_EVAL is an option too
494 2012-01-14 17:56:44 <sipa> gmaxwell: bleh
495 2012-01-14 17:56:56 <justmoon> -"I guess"
496 2012-01-14 17:57:02 <sipa> because that is one thing that OP_EVAL allowed us in a very sane way
497 2012-01-14 17:57:11 <Eliel> luke-jr: you remember the 2 of 2 thing casascius was planning for the more valuable coins he's making? those with two private keys from different parties.
498 2012-01-14 17:57:31 <gmaxwell> Eliel: non-solution.
499 2012-01-14 17:57:41 <justmoon> sipa: recall my point that I like P2SH because it gives us time to work on a well thought-out OP_EVAL one day
500 2012-01-14 17:57:43 <luke-jr> Eliel: but does that produce sane sized addresses?
501 2012-01-14 17:57:52 <Eliel> luke-jr: yes
502 2012-01-14 17:58:00 <luke-jr> Eliel: compatible with existing code?
503 2012-01-14 17:58:01 <Eliel> they look just like normal bitcoin addresses.
504 2012-01-14 17:58:01 <sipa> Eliel: i believe EC fiddling is not the answer for that; it is what the scripting language was intended for
505 2012-01-14 17:58:06 <gmaxwell> Eliel: splitting a private key like that still requires the whole private key to be in one persons hands to sign. That one person has the trojan. Game over.
506 2012-01-14 17:58:56 <luke-jr> sipa: as a temporary solution, it could buy time
507 2012-01-14 17:58:57 <Eliel> gmaxwell: ah yes, that part it can't shield from.
508 2012-01-14 17:59:07 <sipa> justmoon: right, we can still do OP_EVAL of course
509 2012-01-14 17:59:09 <gmaxwell> Eliel: whole point of the split wallet security, pretty much.
510 2012-01-14 17:59:19 <luke-jr> hm
511 2012-01-14 17:59:43 <justmoon> sipa: so that would be my answer to that, let's do CHV or BIP16 now, and OP_EVAL when we are ready with our list of changes and plenty of testing
512 2012-01-14 17:59:44 <Eliel> gmaxwell: limiting the exposure helps though. Although, it's not ideal.
513 2012-01-14 17:59:46 <gmaxwell> wallet encryption was buying time.
514 2012-01-14 18:00:11 <luke-jr> gmaxwell: on that note, have you heard of anyone lose their wallet since then?
515 2012-01-14 18:00:18 <gmaxwell> Eliel: no, it really buys nothing over wallet encryption worse it would result in people electing services to be the key joiner and we'll get more mybitcoins.
516 2012-01-14 18:00:26 <sipa> justmoon: then we get the static analysis argument again of course
517 2012-01-14 18:00:47 <gmaxwell> luke-jr: not sure I heard anyone lose their wallets before then, at least not with substantial amounts, ::shrugs::
518 2012-01-14 18:00:58 <luke-jr> sipa: maybe, but by then there might be enough to 1) know static analysis is useless for certain, and 2) new functionality is worth the loss
519 2012-01-14 18:01:18 <sipa> luke-jr: maybe, indeed
520 2012-01-14 18:01:23 <gmaxwell> But the risk vs conventional banking is real even if some of the thefts so far have not been.
521 2012-01-14 18:03:43 <justmoon> sipa: it is possible to do OP_EVAL with static analysis if you don't need to execute the result of calculations, for example you could use an execute bit - we've been over all the ideas
522 2012-01-14 18:04:06 <sipa> yes, indeed
523 2012-01-14 18:04:58 <gmaxwell> It makes me sad that the fix to the op_return stuff seperated the execution. I'd wondered before why it didn't work that way.
524 2012-01-14 18:05:46 <sipa> and it was satoshi himself who changed that behaviour?
525 2012-01-14 18:05:54 <roconnor> gmaxwell: learning about how bitcoin was before OP_RETURN has really lowered my opinion of bitcoin.
526 2012-01-14 18:05:55 <justmoon> sipa: yes
527 2012-01-14 18:06:08 <justmoon> roconnor: in what way?
528 2012-01-14 18:06:31 <justmoon> sipa: or rather, he committed it
529 2012-01-14 18:06:39 <roconnor> justmoon: clearly bitcoin was not as well thought out before it was released as I had imagined.
530 2012-01-14 18:07:10 <justmoon> roconnor: well, trying to plan everything in advance is a good way to make sure your software *never* comes out
531 2012-01-14 18:07:14 <roconnor> true
532 2012-01-14 18:07:41 <roconnor> but I think it is poor to sell bitcoin as a viable currency system, even today.
533 2012-01-14 18:08:02 <luke-jr> roconnor: it's fixable
534 2012-01-14 18:08:17 <sipa> i believe the implementation and design details are hardly relevant to how succesfull it could be as a currency
535 2012-01-14 18:08:31 <roconnor> maybe
536 2012-01-14 18:08:53 <luke-jr> roconnor: however, these things are part of why I reject clones are scams so easily
537 2012-01-14 18:09:01 <luke-jr> because if they REALLY wanted to compete, they'd fix this crap
538 2012-01-14 18:09:47 <sipa> an alt chain doesn't need to compete if its purpose is to test the viability of a particular change
539 2012-01-14 18:09:56 <luke-jr> I think I should have left names out of my P2SH poll
540 2012-01-14 18:10:15 <luke-jr> sipa: such an alt chain should be a testnet, not a clone with a name/market
541 2012-01-14 18:10:22 <sipa> as long as they don't mislead people into thinking they will replace bitcoin
542 2012-01-14 18:10:31 <luke-jr> too many people are voting for BIP16 just because I associated it with Gavin
543 2012-01-14 18:10:45 <luke-jr> leaving out names might have forced people to make a decision based on tech
544 2012-01-14 18:11:01 <sipa> voting will leave the decision to those who are least informed
545 2012-01-14 18:11:05 <justmoon> or based on which solution's name sounds best
546 2012-01-14 18:11:07 <gmaxwell> luke-jr: you can't know that, perhaps they read my posts and were convinced? :-/
547 2012-01-14 18:11:23 <luke-jr> gmaxwell: well, we know the poll results are meaningless from the control options :p
548 2012-01-14 18:11:27 <pusle> very few are capable of making an informed decision on this on their own
549 2012-01-14 18:11:33 <gmaxwell> luke-jr: though your "I like mudkips" options indicate .. yea.
550 2012-01-14 18:11:36 <luke-jr> gmaxwell: and the comments seem to mostly be saying "I'll just trust Gavin"
551 2012-01-14 18:11:38 <roconnor> case OP_RETURN:
552 2012-01-14 18:11:40 <roconnor> {
553 2012-01-14 18:11:41 <roconnor> pc = pend;
554 2012-01-14 18:11:43 <roconnor> }
555 2012-01-14 18:11:44 <roconnor> heh
556 2012-01-14 18:11:46 <roconnor> old bitcoin code is so funny
557 2012-01-14 18:11:53 <roconnor> in retrospect
558 2012-01-14 18:12:02 <sipa> haha
559 2012-01-14 18:12:16 <justmoon> In retrospect it becomes clear that hindsight is definitely overrated!
560 2012-01-14 18:12:26 <justmoon> - ALFRED E. NEUMAN, Mad Magazine
561 2012-01-14 18:12:47 <roconnor> //
562 2012-01-14 18:12:49 <roconnor> // Script is a stack machine (like Forth) that evaluates a predicate
563 2012-01-14 18:12:50 <roconnor> // returning a bool indicating valid or not. There are no loops.
564 2012-01-14 18:12:52 <roconnor> //
565 2012-01-14 18:13:08 <sipa> if only it had remained a stack machine
566 2012-01-14 18:13:16 <gmaxwell> roconnor: Still a remarkable system e.g. that it had script at all. even if there were some gaffs initially. :)
567 2012-01-14 18:13:16 <sipa> and scriptSig only contained pushes
568 2012-01-14 18:13:26 <roconnor> gmaxwell: ya, I guess that is true
569 2012-01-14 18:13:50 <roconnor> gmaxwell: or at least that is the flip side.
570 2012-01-14 18:14:24 <sipa> exactly, i think Satoshi's vision that scripting would be useful and was possible in this system, is far more important than any design or implementation flaw he did
571 2012-01-14 18:14:38 <gmaxwell> I think it's clear enough that if he'd took a step back on the scope we wouldn't have had those issues. But we'd be far poorer with it.
572 2012-01-14 18:14:59 <roconnor> gmaxwell: right, that is the two sides
573 2012-01-14 18:15:18 <luke-jr> at least he didn't embed Java.
574 2012-01-14 18:15:34 <roconnor> luke-jr: or put javascript into browsers
575 2012-01-14 18:16:16 <roconnor> or put javascript into PDF
576 2012-01-14 18:16:42 <roconnor> my god, there could have been javascript in bitcoin
577 2012-01-14 18:16:44 <gmaxwell> I guess it's also evidence that he couldn't have reasonable done anything more. The complexity was just at the level where he was making mistakes.
578 2012-01-14 18:17:08 <gmaxwell> roconnor: yea, you've not had this thought excercise how many awful things were _not_ done?
579 2012-01-14 18:35:17 <CIA-100> libbitcoin: Kamil Domanski * ra007ea39b8ca / (3 files in 3 dirs): discovery: we are joining a channel http://tinyurl.com/6uqh6gv
580 2012-01-14 18:39:45 <gavinandresen> luke-jr: Did I miss something in your CHV code that prevents somebody from creating transactions that are valid for new clients but invalid for old?
581 2012-01-14 18:41:25 <luke-jr> gavinandresen: that's one of those "the problem just isn't there" things ;)
582 2012-01-14 18:41:33 <luke-jr> gavinandresen: if it succeeds, it has a NOP effect
583 2012-01-14 18:41:36 <luke-jr> gavinandresen: if it fails, it aborts
584 2012-01-14 18:41:47 <gavinandresen> Really?  What would this do:  OP_CODESEP OP_1  :  OP_DROP <hash of OP_1> OP_EQUAL
585 2012-01-14 18:41:58 <gavinandresen> (where : is the scriptSig/ScriptPubKey separator)
586 2012-01-14 18:42:13 <luke-jr> gavinandresen: same thing it currently does&?
587 2012-01-14 18:42:14 <gavinandresen> ... under the old and new rules.
588 2012-01-14 18:42:24 <luke-jr> you didn't use the new instruction at all there
589 2012-01-14 18:42:43 <gavinandresen> Right, but the new EvalScript puts a codehash on the front of the stack
590 2012-01-14 18:42:52 <luke-jr> and then pulls it off
591 2012-01-14 18:43:04 <gavinandresen> What pulls it off?
592 2012-01-14 18:43:10 <luke-jr> EvalScript, for scriptPubKey
593 2012-01-14 18:43:36 <luke-jr> admittedly, a better implementation would replace the 'stack' parameter with a full 'interpretor state'
594 2012-01-14 18:43:40 <gavinandresen> EvalScript(OP_CODESEP OP_1) leaves what on the stack?
595 2012-01-14 18:44:01 <luke-jr> gavinandresen: at the beginning of EvalScript(OP_DROP <hash of OP_1> OP_EQUAL), only {1}
596 2012-01-14 18:44:36 <luke-jr> if (!stack.empty()) { vchLastScript = stack.front(); stack.erase(stack.begin()); }
597 2012-01-14 18:45:07 <gavinandresen> EvalScript is called twice-- once for the scriptSig and once for the scriptPubKey, yes?
598 2012-01-14 18:45:21 <luke-jr> yes
599 2012-01-14 18:45:23 <gavinandresen> And the only state shared between them is the stack after evaluating scriptSig
600 2012-01-14 18:45:43 <gavinandresen> yes?
601 2012-01-14 18:45:43 <luke-jr> currently, and with this implementation, yes
602 2012-01-14 18:46:20 <gavinandresen> Ok.  So after evaluating the scriptSig: OP_CODESEP OP_1 the state of the stack is.....  <code hash> OP_1  for new implementation, right?
603 2012-01-14 18:46:44 <luke-jr> after EvalScript(scriptSig) completes, and before EvalScript(scriptPubKey) begins, yes
604 2012-01-14 18:47:21 <luke-jr> then when EvalScript(scriptPubKey) begins, before it executes, it pulls vchLastScript off the stack
605 2012-01-14 18:47:24 <gavinandresen> So if the scriptPubKey is OP_DROP <hash of OP_1> OP_EQUAL, that will FAIL on old software but succeed on new.
606 2012-01-14 18:47:47 <luke-jr> no, because when scriptPubKey executes, <code hash> has already been removed
607 2012-01-14 18:47:52 <gavinandresen> ... and that is a pretty big problem, because any merchants that haven't upgraded their software will reject the new blockchain
608 2012-01-14 18:48:13 <gavinandresen> <code hash> is removed by what?
609 2012-01-14 18:48:23 <luke-jr> [14:44:36] <luke-jr> if (!stack.empty()) { vchLastScript = stack.front(); stack.erase(stack.begin()); }
610 2012-01-14 18:48:35 <luke-jr> https://github.com/luke-jr/bitcoin/commit/51decbe12f05d32f13b455852e139d6c3c5ef82e#L0R248
611 2012-01-14 18:49:18 <gavinandresen> Comments in your code would be nice, by the way....
612 2012-01-14 18:51:21 <luke-jr> good idea
613 2012-01-14 18:52:27 <gavinandresen> Changing the semantics of EvalScript seems... wrong to me.  At the very least, your change woud break a bunch of unit tests.
614 2012-01-14 18:53:54 <luke-jr> would it be better, to add a new parameter to the function?
615 2012-01-14 18:54:18 <luke-jr> I suppose I could refactor the stack into a general "interp state" class, but that would use more lines of code, which you seem to dislike in the past
616 2012-01-14 18:54:37 <gavinandresen> So calling EvalScript with the scriptPubKey on new clients, if there is no CHV in the scriptPubKey an extra item is put on the front of the stack just before EvalScript ends.... that seems exploitable to me, too
617 2012-01-14 18:56:03 <gavinandresen> Frankly, I don't want to spend more time tweaking CHV or anything like it-- /P2SH/ is perfectly fine, and has well-defined semantics that we've already spent the time tweaking and thinking about.
618 2012-01-14 18:57:32 <[Tycho]> Finally a constructive discussion :)
619 2012-01-14 18:58:35 <luke-jr> gavinandresen: that might be a concern, I can refactor it to avoid using the stack easily
620 2012-01-14 19:00:11 <gavinandresen> Tycho, what are you thinking recently?  I know you liked OP_EVAL better than /P2SH/, have you been keeping up with all the discussion?
621 2012-01-14 19:05:07 <luke-jr> gavinandresen: OK, it now doesn't touch the stack, just using a new variable for safety
622 2012-01-14 19:05:44 <CIA-100> bitcoin: Luke Dashjr checkhashverify * rf026234cf4ed bitcoind-personal/src/ (main.cpp script.cpp script.h): DRAFT: OP_CHECKHASHVERIFY http://tinyurl.com/6oqokt3
623 2012-01-14 19:05:45 <CIA-100> bitcoin: Luke Dashjr checkhashverify * r8b23d4839dfa bitcoind-personal/src/script.cpp: DRAFT: OP_CHECKHASHVERIFY with hash specified http://tinyurl.com/899za86
624 2012-01-14 19:06:19 <luke-jr> (first one is the revision, second one just a theoretical addition)
625 2012-01-14 19:07:01 <luke-jr> on GitHub, https://github.com/luke-jr/bitcoin/commit/f026234cf4edc53de4d9e60ccea581adbcb8ee3c
626 2012-01-14 19:10:30 <CIA-100> libbitcoin: genjix * rc77cd1ace1d5 / (6 files in 4 dirs): Finalised API based off experience with block-exploiter. Future changes: http://tinyurl.com/6v7jhrp
627 2012-01-14 19:11:27 <Joric> block-exploiter ?
628 2012-01-14 19:12:02 <gavinandresen> luke-jr: by the time you're done tweaking CHV will be uglier than /P2SH/.  Example:  standard checksig transaction is  <pubkey> CHECKSIG if in the scriptPubKey, but must be <pubkey> CHECKSIGVERIFY if used in the scriptSig of a CHV....
629 2012-01-14 19:13:06 <luke-jr> gavinandresen: is that a problem?
630 2012-01-14 19:13:37 <luke-jr> worst case scenario, the scriptSig needs an extra OP_VERIFY
631 2012-01-14 19:13:48 <luke-jr> and as you mention, there's a combined form for the common case
632 2012-01-14 19:13:58 <gavinandresen> Just more code, more inconsistency, more possibility for somebody to screw up and use CHECKSIG accidently and then be surprised when their coins are stolen
633 2012-01-14 19:15:03 <luke-jr> not nearly as much inconsistency as BIP16
634 2012-01-14 19:15:11 <gavinandresen> Again, I would really prefer not to spend more time trying to think of all the possible ways CHV might be broken.  I like /P2SH/ because it is REALLY HARD for it to be broken
635 2012-01-14 19:17:29 <luke-jr> CHV no longer modified the stack at any point, I'd be surprised to see how it could possibly be broken in this form
636 2012-01-14 19:17:30 <gavinandresen> Gotta go, see y'all later.
637 2012-01-14 19:17:34 <luke-jr> ttyl
638 2012-01-14 19:21:46 <roconnor> what happens when stack.at is called with an out of bounds parameter?
639 2012-01-14 19:21:51 <roconnor> is there boundschecking?
640 2012-01-14 19:22:29 <luke-jr> roconnor: crash I think
641 2012-01-14 19:22:34 <luke-jr> probably not
642 2012-01-14 19:22:37 <luke-jr> it's inside a try{} tho
643 2012-01-14 19:22:41 <luke-jr> so it could be OK
644 2012-01-14 19:30:30 <roconnor> ah crap
645 2012-01-14 19:30:45 <roconnor> it looks like invalid opcodes in unused IF branches are legal
646 2012-01-14 19:31:15 <roconnor> time for me to add new strange transactions to testnet
647 2012-01-14 19:32:06 <k9quaint> every time I fail a CAPTCHA test I feel as though a little bit of my humanity has been stripped from me :(
648 2012-01-14 19:32:23 <pusle> :P
649 2012-01-14 19:33:42 <luke-jr> k9quaint: FreeNode's webchat is DIFFICULT :/
650 2012-01-14 19:33:48 <luke-jr> at least at 300 dpi
651 2012-01-14 19:34:30 <roconnor> wow
652 2012-01-14 19:34:41 <roconnor> I don't see "loop" used much in C++/C code
653 2012-01-14 19:35:46 <luke-jr> roconnor: I think it's a Bitcoin-specific macro actually
654 2012-01-14 19:35:53 <roconnor> oh
655 2012-01-14 19:40:15 <CIA-100> libbitcoin: Kamil Domanski * r90d99d0a7095 / (2 files in 2 dirs): discovery: random number generator seeded http://tinyurl.com/7on7xv8
656 2012-01-14 19:44:18 <luke-jr> http://blockchain.info/tx-index/14302004/8af10d2e14c488017714e62b9b36905f934b6b36217b54ad660658ed8dc5a905
657 2012-01-14 19:45:13 <roconnor> luke-jr: is that an unusual transaction?
658 2012-01-14 19:45:39 <luke-jr> roconnor: last payout from Eligius-Su
659 2012-01-14 19:46:17 <gmaxwell> luke-jr: have you redirected the old hostname to the new?
660 2012-01-14 19:46:36 <luke-jr> gmaxwell: yes, the IP as well
661 2012-01-14 19:47:14 <luke-jr> gmaxwell: and even then, I had to kill pushpool to stop some people -.-
662 2012-01-14 19:49:10 <roconnor> luke-jr: does blockchain-info work for testnet?
663 2012-01-14 19:53:42 <luke-jr> roconnor: no idea
664 2012-01-14 19:53:45 <luke-jr> piuk runs it
665 2012-01-14 20:00:51 <gribble> New news from bitcoinrss: Matoking opened pull request 758 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/758>
666 2012-01-14 20:03:52 <roconnor> sipa: OP_UNKNOWN: http://blockexplorer.com/testnet/tx/16818827541394f36bf873f44ace4e97116f51a0cd92242353db37677519cfc5
667 2012-01-14 20:04:01 <roconnor> I think my code will fail here :(
668 2012-01-14 20:04:40 <luke-jr> >_<
669 2012-01-14 20:05:01 <roconnor> putting this into the testnet chain will remind me to fix it
670 2012-01-14 20:12:05 <[Tycho]> Still unconfirmed :)
671 2012-01-14 20:13:42 <gmaxwell> AcceptToMemoryPool(): accepted 1681882754
672 2012-01-14 20:14:38 <gmaxwell> hmph. where is that switch.
673 2012-01-14 20:14:53 <gmaxwell> oh there it is ..
674 2012-01-14 20:15:03 <gmaxwell> one block..
675 2012-01-14 20:15:05 <roconnor> gmaxwell: I have 9 confirmations
676 2012-01-14 20:15:07 <gmaxwell> two block
677 2012-01-14 20:15:08 <roconnor> 10
678 2012-01-14 20:15:10 <gmaxwell> ah okay.
679 2012-01-14 20:15:21 <roconnor> 11
680 2012-01-14 20:15:48 <gmaxwell> yea, I just mined a couple, didn't realize you had ones already. Cool.
681 2012-01-14 20:15:58 <roconnor> more the better
682 2012-01-14 20:16:00 <roconnor> :D
683 2012-01-14 20:16:17 <gmaxwell> I could remove it too if someone wants. ;)
684 2012-01-14 20:16:25 <roconnor> *l*
685 2012-01-14 20:16:41 <roconnor> better mine until you cannot remove it ;)
686 2012-01-14 20:16:43 <roconnor> :P
687 2012-01-14 20:17:06 <roconnor> actually I'd rather the difficulty stay low
688 2012-01-14 20:17:14 <gmaxwell> yea...
689 2012-01-14 20:18:37 <sipa> roconnor: how can that be accepted?
690 2012-01-14 20:18:40 <sipa> case default:
691 2012-01-14 20:18:43 <sipa> return false;
692 2012-01-14 20:18:50 <roconnor> it is never run
693 2012-01-14 20:18:56 <roconnor> it is in the non-run OP_IF branch
694 2012-01-14 20:19:02 <sipa> aargh
695 2012-01-14 20:19:30 <roconnor> I keep tryin to find a break using OP_IF and deserialization of scripts, but I can't quite make it break.
696 2012-01-14 20:19:46 <sipa> well, it deserializes during execution
697 2012-01-14 20:19:51 <sipa> there is no invalid script data
698 2012-01-14 20:20:00 <roconnor> kinda
699 2012-01-14 20:20:10 <roconnor> if you think every byte is a validish op_code
700 2012-01-14 20:20:21 <roconnor> my code doesn't feel that way at the moment.
701 2012-01-14 20:20:53 <roconnor> (because I thought every bad opcode would hit that default case and always eventually fail)
702 2012-01-14 20:21:22 <roconnor> actually there are 2 opcodes that will always fail
703 2012-01-14 20:21:31 <roconnor> OP_VERIF and the otherone
704 2012-01-14 20:21:56 <roconnor> OP_VERNOTIF
705 2012-01-14 20:26:08 <mtrlt> auto it = bla.begin();  c++11 <3
706 2012-01-14 20:26:34 <sipa> ooh, nice!
707 2012-01-14 20:27:08 <gmaxwell> they're reusing the auto keyword for that?
708 2012-01-14 20:27:26 <sipa> static only has 3 three meanings already, auto could use a couple more
709 2012-01-14 20:28:11 <mtrlt> it's not like auto has been used extensively in the other meaning :P
710 2012-01-14 20:28:13 <gmaxwell> "By learn from your mistakes& you meant so we could keep repeating them. ... Right?"
711 2012-01-14 20:28:16 <mtrlt> at least in the 2000s
712 2012-01-14 20:28:36 <gmaxwell> mtrlt: it's a language artifact pretty much.
713 2012-01-14 20:29:00 <gmaxwell> From the dmr compiler, iirc.
714 2012-01-14 20:42:37 <Eliel> gmaxwell: no automated way of detecting mistakes that would be lighter and work better than the process making the choices already :P
715 2012-01-14 20:47:18 <gmaxwell> Anyone know of any crash bugs related to the qt gui and concurrent rpc calls?
716 2012-01-14 20:47:59 <gmaxwell> p2pool users using bitcoin-qt have been reporting crashes though since they're all windows users so far I'm sort of limited in the troubleshooting I can have them do.
717 2012-01-14 20:48:07 <gmaxwell> I did validate that 0.5.2rc doesn't fix it.
718 2012-01-14 20:50:23 <ThomasV_> luke-jr: https://bitcointalk.org/index.php?topic=58534.0;topicseen
719 2012-01-14 20:55:07 <gmaxwell> in theory ssl solves that???but there is no way for a normal user to store evidence of their ssl session in a way they could use to prove it to anyone else.
720 2012-01-14 20:55:48 <gmaxwell> ThomasV_: unfortunately I could just generate a random signing address for a user I was going to defraud.
721 2012-01-14 20:56:09 <gmaxwell> then when he gets ripped off he'd find the address didn't match the one on the site or in internetarchive/etc.
722 2012-01-14 20:56:15 <sipa> ThomasV_: https://gist.github.com/1237788 :)
723 2012-01-14 20:57:24 <gmaxwell> Yea, the sipa protocol solves that iirc.
724 2012-01-14 21:30:16 <CIA-100> libbitcoin: Kamil Domanski * rb2e86d22db80 /include/bitcoin/network/discovery.hpp: discovery: made methods private http://tinyurl.com/83hq2tf
725 2012-01-14 21:30:17 <CIA-100> libbitcoin: Kamil Domanski * rf4d3aff24825 /src/network/discovery.cpp: discovery: respond to PING http://tinyurl.com/7zahums
726 2012-01-14 22:43:17 <roconnor> whee
727 2012-01-14 22:43:27 <roconnor> processing block: 000000000123de298952f0bea8eb79248e3c0ca181c0a004dadfc02354d6d357:2012-01-14 21:02:36 UTC:1
728 2012-01-14 22:43:29 <roconnor> Main: Failed reading: Unknown OP code: 240
729 2012-01-14 22:43:42 <roconnor> >_<
730 2012-01-14 22:44:35 <gmaxwell> Expected result was ... unexpected?
731 2012-01-14 22:45:07 <roconnor> well I expected my code to fail on my transaction.
732 2012-01-14 22:45:12 <roconnor> just thought I should check
733 2012-01-14 22:45:44 <roconnor> It's really hard to reimplement bitcoin
734 2012-01-14 22:52:31 <lianj> but fun
735 2012-01-14 22:52:38 <roconnor> but fun
736 2012-01-14 22:55:34 <lianj> btw, is there a p2sh tx in testnet that i can take as a fixture?
737 2012-01-14 22:57:43 <roconnor> browsing historical code in github confuses me
738 2012-01-14 23:00:04 <roconnor> if (!EvalScript(txin.scriptSig + CScript(OP_CODESEPARATOR) + txout.scriptPubKey, txTo, nIn))
739 2012-01-14 23:00:06 <roconnor> is so bad
740 2012-01-14 23:00:31 <roconnor> scriptSig could contain a partial PUSHDATA operation, thus incorporating the OP_CODESEPARATOR into the pushdata, instead of being an operation
741 2012-01-14 23:00:56 <gmaxwell> roconnor: is that actually how those objects work?
742 2012-01-14 23:01:07 <gmaxwell> or is it concating the parsed data?
743 2012-01-14 23:01:14 <roconnor> + runs vector<unsigned char> concatinatino
744 2012-01-14 23:01:27 <gmaxwell> oh. sounds like it then.
745 2012-01-14 23:03:11 <sipa> looks like it, yes
746 2012-01-14 23:03:16 <roconnor> maybe I should stop debugging 2010 code
747 2012-01-14 23:07:30 <gmaxwell> roconnor: be happy when the lshift/return bug was fixed the fix also fixed other possible attacks, evidence again that the development process works. :)
748 2012-01-14 23:22:55 <JFK911> shift-return bug?
749 2012-01-14 23:27:22 <lianj> for BIP_0011, "But only for n less than or equal to 3." - so n can only be OP_2 and OP_3 ?
750 2012-01-14 23:29:00 <sipa> roconnor: makes me wonder where script concatenations are used otherwise
751 2012-01-14 23:36:00 <roconnor> sipa: thats a good point
752 2012-01-14 23:36:07 <roconnor> they are also used in assembling scripts
753 2012-01-14 23:36:21 <roconnor> maybe I should look at the template matching code
754 2012-01-14 23:36:31 <sipa> only for locally-created scripts, afaik
755 2012-01-14 23:36:41 <sipa> but i'm wouldn't vouch for it..