1 2011-12-28 00:31:04 <CIA-100> bitcoinjs/node-bitcoin-p2p: Stefan Thomas master * r8882109 / README.md : Update README. - http://git.io/ks6Gcg https://github.com/bitcoinjs/node-bitcoin-p2p/commit/8882109efdcc0f3cc98d5a9cccaede82aea47280
  2 2011-12-28 02:15:19 <CIA-100> bitcoinjs/node-bitcoin-exit: booo master * r076053b / (README.md block.js package.json pubkeys.js server.js tx.js): rename bitcoin-p2p into bitcoinjs - http://git.io/mxgZ5A https://github.com/bitcoinjs/node-bitcoin-exit/commit/076053b40a41e7987c44b97f835875bbdace2ab2
  3 2011-12-28 06:51:42 <finway> Wow, seems yesterday was a busy talky buggy day.
  4 2011-12-28 06:51:49 <finway> ;;bc
  5 2011-12-28 06:51:50 <gribble> Error: "bc" is not a valid command.
  6 2011-12-28 07:44:49 <blue_> hi, the "Previous tx"  is the previous transaction of the sender right?
  7 2011-12-28 07:46:33 <BlueMatt> you mean on blockexplorer?
  8 2011-12-28 07:47:04 <BlueMatt> wumpus: why do all the sends in my wallet say "Sent to IP" in bitcoin-qt?
  9 2011-12-28 07:48:12 <CIA-100> bitcoinjs/node-bitcoin-exit: Stefan Thomas master * rb5d4b63 / (package.json pubkeys.js tx.js): Updates for BitcoinJS 0.2. - http://git.io/CyHJoA https://github.com/bitcoinjs/node-bitcoin-exit/commit/b5d4b6301ca4e350a0a9bf8803bf23e4de9a0679
 10 2011-12-28 07:48:35 <lolcat> I have Tails!
 11 2011-12-28 07:58:05 <phantomcircuit> BlueMatt, sounds like a bug
 12 2011-12-28 07:58:20 <BlueMatt> phantomcircuit: I would say so...
 13 2011-12-28 08:02:43 <wumpus> BlueMatt: haven't heard of that problem before; since what release?
 14 2011-12-28 08:02:55 <BlueMatt> wumpus: nfc, it does on current head
 15 2011-12-28 08:02:57 <wumpus> or /commit
 16 2011-12-28 08:02:59 <BlueMatt> the wallet is old as balls though
 17 2011-12-28 08:04:43 <wumpus> it labels to transaction as sent to ip if transaction map "to" and "from" fields don't have a value
 18 2011-12-28 08:05:01 <wumpus> uh wait, that's the other wait around
 19 2011-12-28 08:05:13 <BlueMatt> the wallet was created in feb (I think)
 20 2011-12-28 08:05:15 <BlueMatt> maybe earlier
 21 2011-12-28 08:05:20 <wumpus> *IF* they have a value
 22 2011-12-28 08:05:31 <wumpus> what does it say as sender/receiver?
 23 2011-12-28 08:06:00 <wumpus> else if (!mapValue["from"].empty() || !mapValue["message"].empty())
 24 2011-12-28 08:06:01 <wumpus> {
 25 2011-12-28 08:06:02 <BlueMatt> I have a To: (the name of an address) but no from
 26 2011-12-28 08:06:33 <wumpus> and thten uses the content of the "from" field as IP address
 27 2011-12-28 08:06:59 <BlueMatt> there is no from in the popup of the tx
 28 2011-12-28 08:07:34 <wumpus> that's one weird wallet then
 29 2011-12-28 08:08:00 <BlueMatt> its been around the block, but its not even encrypted
 30 2011-12-28 08:08:12 <BlueMatt> let me get some dumps and see what happens...
 31 2011-12-28 08:10:06 <wumpus> yes it'd be interesting to see how it differs from a "normal" wallet on a low level
 32 2011-12-28 08:11:53 <BlueMatt> ok, well its gonna take like an hour and a half to remove private info from the dump, but Ill have it in an hour or so...
 33 2011-12-28 08:17:45 <blue_> in a Block - what is the "Merkle root" is it the difficulti or is it some kind of Blockchain proof?
 34 2011-12-28 08:18:38 <BlueMatt> its the head of a merkle tree of the hashes of the txes in the block
 35 2011-12-28 08:18:47 <BlueMatt> see also: http://en.wikipedia.org/wiki/Merkle_tree
 36 2011-12-28 08:19:01 <BlueMatt> its essentially just a hash of the list of txes
 37 2011-12-28 08:19:16 <BlueMatt> though it allows for tx pruning
 38 2011-12-28 08:19:35 <blue_> but  Merkle_tree != Block Hash?
 39 2011-12-28 08:21:02 <BlueMatt> no, its part of the header, which is hashed to get block hash
 40 2011-12-28 08:21:21 <BlueMatt> the header is what you have to brute-force to get a block hash < target
 41 2011-12-28 08:21:29 <BlueMatt> by incrementing nonce
 42 2011-12-28 08:22:18 <blue_> ok good
 43 2011-12-28 08:22:57 <blue_> the the merkle tree seems to be som kind of hash over the transaktion hashs in the current block?
 44 2011-12-28 08:24:44 <BlueMatt> exactly
 45 2011-12-28 08:25:05 <blue_> :) ty
 46 2011-12-28 08:25:44 <BlueMatt> np
 47 2011-12-28 08:36:19 <blue_> Is there a maximum of transaktions in a single block?
 48 2011-12-28 08:37:04 <BlueMatt> no, but current clients limit blocksize to X MB
 49 2011-12-28 08:37:17 <BlueMatt> though that would eventually be removed if it because a limiting factor
 50 2011-12-28 08:38:06 <blue_> are you a developer from the Bitcoins team?
 51 2011-12-28 08:38:16 <ThomasV> do current clients accept a mined block or arbitrary size?
 52 2011-12-28 08:38:32 <BlueMatt> ThomasV: huh?
 53 2011-12-28 08:38:51 <BlueMatt> blue_: not really, though last time I checked I think I had like the 4th or 5th most commits...
 54 2011-12-28 08:39:36 <ThomasV> BlueMatt: the blocksize limit is only for mining, is it not?
 55 2011-12-28 08:40:20 <BlueMatt> ThomasV: I thought it was enforced by the net code, but Im not 100% sure, its been a long time
 56 2011-12-28 08:40:26 <blue_> :D
 57 2011-12-28 08:40:31 <ThomasV> I am not sure either
 58 2011-12-28 08:40:46 <ThomasV> but I think there are past blocks with very large number of tx
 59 2011-12-28 08:40:57 <BlueMatt> yea, but no where near the 10 MB limit
 60 2011-12-28 08:41:03 <BlueMatt> (is it 10 or 100)
 61 2011-12-28 08:41:13 <BlueMatt> I can never remember the actual limit, but its a power of 10
 62 2011-12-28 08:41:30 <ThomasV> what is the current average block size?
 63 2011-12-28 08:41:41 <BlueMatt> there was a page that calculated that
 64 2011-12-28 08:41:49 <BlueMatt> not like I would ever remember where why how
 65 2011-12-28 08:42:01 <ThomasV> I mean approximately
 66 2011-12-28 08:42:25 <BlueMatt> nfc anymore
 67 2011-12-28 08:42:33 <blue_> hm it would take more time to find such a big thing -so you would start over and over to much i guess
 68 2011-12-28 08:43:06 <BlueMatt> blue_: #5 according to bitcoin.org, but # commits really means nothing...
 69 2011-12-28 08:43:36 <blue_> kay
 70 2011-12-28 08:44:05 <BlueMatt> just means I have no life and can write small fixes all day long
 71 2011-12-28 08:44:13 <BlueMatt> :)
 72 2011-12-28 08:46:17 <SomeoneWeird> fuuu, anyone have experience with android rooting?
 73 2011-12-28 08:47:22 <SomeoneWeird> yeah i just tried rooting my xoom, wont go past the boot logo now :'(
 74 2011-12-28 08:47:47 <BlueMatt> ouch
 75 2011-12-28 08:47:52 <BlueMatt> can you boot into recovery from adb?
 76 2011-12-28 08:48:04 <BlueMatt> or otherwise
 77 2011-12-28 08:48:53 <SomeoneWeird> yeh i can
 78 2011-12-28 08:49:44 <SomeoneWeird> and it comes up with it when i do adb devices too
 79 2011-12-28 08:49:56 <BlueMatt> so adb reboot recovery and reflash?
 80 2011-12-28 08:50:19 <SomeoneWeird> oo
 81 2011-12-28 08:50:37 <SomeoneWeird> what do i reflash with?
 82 2011-12-28 08:50:38 <SomeoneWeird> lol
 83 2011-12-28 08:51:44 <BlueMatt> a rom zip?
 84 2011-12-28 08:51:56 <SomeoneWeird> mm
 85 2011-12-28 08:52:00 <SomeoneWeird> may as well flash ICS then
 86 2011-12-28 08:52:04 <BlueMatt> or does android stock recovery not have the zip flash option?
 87 2011-12-28 08:52:13 <BlueMatt> (is that a custom recovery-only feature?)
 88 2011-12-28 08:52:21 <BlueMatt> Im not really that experienced (as you can see...)
 89 2011-12-28 08:53:04 <SomeoneWeird> no idea
 90 2011-12-28 08:53:22 <BlueMatt> ;;later tell gavinandresen if you get the chance, can you write/copy stuff about op_eval to the wiki's script page (and maybe make an OP_EVAL page) https://en.bitcoin.it/wiki/Script
 91 2011-12-28 08:53:23 <gribble> The operation succeeded.
 92 2011-12-28 08:53:38 <SomeoneWeird> ok so i put it into its recovery mode
 93 2011-12-28 08:53:44 <BlueMatt> well how did you flash it to begin with?
 94 2011-12-28 08:53:45 <SomeoneWeird> now theres an android with a warning symbol
 95 2011-12-28 08:53:47 <SomeoneWeird> i didn't
 96 2011-12-28 08:53:52 <SomeoneWeird> havn't
 97 2011-12-28 08:53:54 <BlueMatt> so why is it not booting?
 98 2011-12-28 08:53:58 <BlueMatt> odin?
 99 2011-12-28 08:54:09 <SomeoneWeird> trying to root it
100 2011-12-28 08:54:20 <BlueMatt> does xoom have sgii-style pre-recovery flash tool like oding on the sgii?
101 2011-12-28 08:54:28 <SomeoneWeird> oding?
102 2011-12-28 08:54:39 <BlueMatt> how were you rooting it, software hack, kernel flash, rom flash?
103 2011-12-28 08:55:14 <SomeoneWeird> oh
104 2011-12-28 08:55:17 <SomeoneWeird> kernel flash i think
105 2011-12-28 08:55:26 <SomeoneWeird> http://forum.xda-developers.com/showthread.php?t=1010568
106 2011-12-28 08:55:30 <SomeoneWeird> i was following that
107 2011-12-28 08:56:50 <BlueMatt> oh, software exploit...
108 2011-12-28 08:56:58 <BlueMatt> well I have nfc what to do on the xoom
109 2011-12-28 08:56:59 <SomeoneWeird> oh
110 2011-12-28 08:57:05 <BlueMatt> isnt there a xoom irc chan on here?
111 2011-12-28 08:57:08 <SomeoneWeird> mm, thanks anyway
112 2011-12-28 08:57:22 <SomeoneWeird> oh look there is, ahh
113 2011-12-28 08:58:49 <BlueMatt> anyone have the link to that 49.999... btc-generating block?
114 2011-12-28 08:58:58 <BlueMatt> midnightmagic: ?
115 2011-12-28 08:59:00 <BlueMatt> wasnt that you?
116 2011-12-28 09:00:02 <lolcat> BlueMatt: Has the injection happened allready? Oo
117 2011-12-28 09:00:17 <lfm> The one where they didnt claim the whol 50 btc? ya I can get it
118 2011-12-28 09:00:18 <BlueMatt> nvm, found it
119 2011-12-28 09:00:22 <BlueMatt> lolcat: ?
120 2011-12-28 09:00:25 <BlueMatt> http://blockexplorer.com/block/0000000000004c78956f8643262f3622acf22486b120421f893c0553702ba7b5
121 2011-12-28 09:00:57 <lolcat> BlueMatt: I heard rumors of a block injection
122 2011-12-28 09:01:10 <epscy> !ticker
123 2011-12-28 09:01:14 <BlueMatt> lolcat: meaning?
124 2011-12-28 09:01:19 <epscy> !ticker
125 2011-12-28 09:01:20 <gribble> Best bid: 4.11, Best ask: 4.112, Bid-ask spread: 0.002, Last trade: 4.1121, 24 hour volume: 34681, 24 hour low: 3.962, 24 hour high: 4.18888
126 2011-12-28 09:01:28 <lolcat> BlueMatt: They falsely injected a block into the chain
127 2011-12-28 09:01:37 <lolcat> Or where going to
128 2011-12-28 09:01:39 <BlueMatt> and how would one do that?
129 2011-12-28 09:01:49 <BlueMatt> you mean like add another block in the middle of the chain?
130 2011-12-28 09:02:25 <BlueMatt> that would mean you would need a sha256 collision, which so far no known collisions have been found, so have fun brute forcing for the next million and a half years
131 2011-12-28 09:04:09 <lolcat> Inject it to the end of the chain I pressume?
132 2011-12-28 09:04:17 <BlueMatt> isnt that called mining?
133 2011-12-28 09:04:41 <lolcat> I don't know, haven't relly looked into it. I found out tenebrix was much easier to mine
134 2011-12-28 09:04:45 <lfm> theres one ... oh and theres another one
135 2011-12-28 09:05:50 <lfm> (blocks added to the end of the chain)
136 2011-12-28 09:05:56 <epscy> real men inject a new genesis block
137 2011-12-28 09:05:58 <BlueMatt> that is called mining?
138 2011-12-28 09:06:19 <BlueMatt> so, uh people are coming up with a new name for mining?
139 2011-12-28 09:06:34 <lolcat> BlueMatt: I see your point, I guess I should not listen to random irc rumors then
140 2011-12-28 09:07:07 <lfm> lolcat duh
141 2011-12-28 09:07:30 <lolcat> lfm: I usually trust people on irc
142 2011-12-28 09:07:38 <BlueMatt> its possibly something new, but if they are injecting blocks into the end of the chain, I believe that is called mining ;)
143 2011-12-28 09:07:39 <wumpus> haha you're in for a world of pain
144 2011-12-28 09:07:40 <lolcat> It is great for buying drugs for instance
145 2011-12-28 09:07:50 <lolcat> wumpus: whom?
146 2011-12-28 09:08:00 <wumpus> lolcat: if you usually trust people on irc
147 2011-12-28 09:08:03 <BlueMatt> heh
148 2011-12-28 09:08:13 <BlueMatt> buying drugs online is always a good idea
149 2011-12-28 09:08:13 <lolcat> wumpus: I've been on irc for at least two years
150 2011-12-28 09:09:03 <lfm> you guy drugs for bitcoins?
151 2011-12-28 09:09:09 <lfm> buy
152 2011-12-28 09:09:25 <epscy> your gay for drugs and bitcoins?
153 2011-12-28 09:09:50 <BlueMatt> yea, getting drugs shipped to you in the mail is always a safe idea...
154 2011-12-28 09:10:01 <epscy> i guess bitcoin prostituition had to start at some point
155 2011-12-28 09:10:24 <mcorlett> BlueMatt: I hope to see what you just said quoted on Encyclopedia Dramatica.
156 2011-12-28 09:10:38 <BlueMatt> mcorlett: add it
157 2011-12-28 09:10:57 <BlueMatt> mcorlett: atleast its more incontext than the one on the bitcoin page there already...
158 2011-12-28 09:11:04 <lfm> if he trust irc people he might as well
159 2011-12-28 09:11:16 <lolcat> lfm: Nah, paypal
160 2011-12-28 09:11:17 <mcorlett> Ha!
161 2011-12-28 09:11:23 <BlueMatt> http://encyclopediadramatica.ch/Bitcoin
162 2011-12-28 09:11:25 <BlueMatt> bottom of the page
163 2011-12-28 09:11:52 <lolcat> BlueMatt: What is wrong with receiving drugs in the mail? It beats risking to get killed by a drug dealer
164 2011-12-28 09:11:59 <lfm> no need for a condom if you pay with bitcoins
165 2011-12-28 09:12:09 <BlueMatt> lolcat: there are no good ways to buy drugs, they all suck
166 2011-12-28 09:12:17 <lolcat> BlueMatt: But drugs doesn't
167 2011-12-28 09:12:20 <BlueMatt> though I do live in a college dorm, so...
168 2011-12-28 09:12:48 <lolcat> I tried making a living selling haitian slaves for  bitcoins, unfortnuatly I didn't make to many sales.
169 2011-12-28 09:12:57 <BlueMatt> anyway, Im off
170 2011-12-28 09:13:01 <BlueMatt> gnight all
171 2011-12-28 09:13:13 <lfm> who paid  171.79869184 btc in fee for one txn anyway?
172 2011-12-28 09:13:29 <lolcat> lfm: thats a lot
173 2011-12-28 09:15:17 <lfm> Block #157235 2011-12-12 16:57:45
174 2011-12-28 09:24:47 <epscy> probably mtgox messing about again
175 2011-12-28 09:25:24 <lfm> Im thinking it more likley some miner playing around paying him,self
176 2011-12-28 09:34:12 <lfm> there some weird extranonce stuff in that same block
177 2011-12-28 09:36:27 <lolcat> extranonce?
178 2011-12-28 09:38:50 <lfm> it looks like it was something to do with yourbtc.net pool shutting down
179 2011-12-28 09:39:19 <lfm> extranonce is the stuff in the coinbase input
180 2011-12-28 09:46:54 <lfm> yourbtc.net pool sez it was shutting down dec 10 but its still running and producing blocks to this day
181 2011-12-28 09:58:51 <Graet> lfm they also said they had been asked to remain open to give miners time to move, so urstroter said he would leave it up for a month but no development etc so ~10jan for real
182 2011-12-28 11:06:14 <UukGoblin> hm, on http://bitcoin.org/about.html - change "broadcasted" to "broadcast" - it's an irregular verb
183 2011-12-28 11:06:56 <UukGoblin> oh, maybe not everywhere now... eh, natlangs.
184 2011-12-28 13:35:11 <CIA-100> bitcoin: jedi95 * r3fb7c12e82d3 Phoenix-Miner/ (Miner.py minerutil/RPCProtocol.py): Fixed unhandled exception in RPCProtocol. AttributeError: 'NoneType' object has no attribute 'close' http://tinyurl.com/cezebq9
185 2011-12-28 15:24:43 <onelineproof> I'm almost done my little wallet reader program. But I noticed that one key had a 31 bit private key instead of 32 bit. Is this a bug or should I take care of this case?
186 2011-12-28 15:24:54 <onelineproof> *byte
187 2011-12-28 15:34:56 <sipa> onelineproof: maybe the first byte is a zero?
188 2011-12-28 15:36:24 <onelineproof> It start's like this 253 22 1 48 130 1 18 2 1 1 4 31
189 2011-12-28 15:36:47 <onelineproof> instead of 253 23 1 48 130 1 19 2 1 1 4 32
190 2011-12-28 15:40:07 <onelineproof> Then it's 31 bytes then 160 129 165 48 129 162 2 1 1 ...
191 2011-12-28 15:40:28 <onelineproof> the normal one is 32 bytes then 160 129 165 48 129 162 2 1 1
192 2011-12-28 15:41:43 <onelineproof> but pywallet just pretends its 32 bytes and uses the 160 as the 32nd byte
193 2011-12-28 15:43:17 <onelineproof> but then when you compute the public key from the private key using elliptic curve point multiplication, the public key you get is not the same as the one that is used (65 bytes)
194 2011-12-28 15:44:41 <onelineproof> but if i treat it as a 31 byte private key then the public keys match, but then the private key to bc format private key converter gives me something that doesn't start with a 5 as usual
195 2011-12-28 15:51:57 <Cryo> sounds like bug.
196 2011-12-28 15:53:43 <gmaxwell> a bug.. in your base 58 decoder.
197 2011-12-28 15:55:14 <onelineproof> no my decoder produces the same result as pywallet if I consider the key as a 32 byte key
198 2011-12-28 15:55:40 <Diablo-D3> so your code is almost done
199 2011-12-28 15:56:19 <onelineproof> but it's not a correct key pair, I doubt it will be able to sign messages that can be verified
200 2011-12-28 15:58:13 <onelineproof> well unless I get a better solution, I'll just print the message invalid key for that key.
201 2011-12-28 16:00:02 <onelineproof> Also I have another question. Has it been proven that finding the logarithm for elliptic curve points is NP-hard?
202 2011-12-28 16:03:24 <sipa> are you DER decoding the private key data yourself?
203 2011-12-28 16:04:05 <sipa> onelineproof: i don't think it is proven NP-hard, no
204 2011-12-28 16:04:06 <onelineproof> I'm using berkeley db to read the key value pairs in the database
205 2011-12-28 16:05:20 <onelineproof> Then I'm using the methods that pywallet and gavin's bitcointools uses to decode the address and private key
206 2011-12-28 16:09:44 <sipa> using openssl?
207 2011-12-28 16:10:36 <sipa> i think the encoding of private keys is nontrivial, and without fixed-lenth garantees
208 2011-12-28 16:11:43 <sipa> at least, openssl's redundant rncoding
209 2011-12-28 16:11:52 <edcba> i think they still have a max length :)
210 2011-12-28 16:13:15 <Diablo-D3> er
211 2011-12-28 16:13:33 <Diablo-D3> bitselect() is the instruction we're using bfi_int for instead, right?
212 2011-12-28 16:23:26 <onelineproof> the 31 byte key should still work fine with the standard client. It's just when you export and treat it as 32 bit, you're not really exporting the private key, and you can't derive the address from it. So maybe pywallet should be careful to not allow such keys.
213 2011-12-28 16:26:51 <sipa> bitcoin 0.6 will support exporting private keys in base59
214 2011-12-28 16:26:58 <sipa> base58
215 2011-12-28 16:27:18 <rjk2> all ur base are belong to bitcoin
216 2011-12-28 16:34:37 <Cryo> Diablo-D3, when you switched to larger work sizes, is the MH/s supposed to drop?  I went from 28Mh/s(-w 32) old version to 14MH/s(-w 128) on the latest version.
217 2011-12-28 16:35:14 <CIA-100> libbitcoin: genjix * r05095e49509a / (10 files in 3 dirs): bdb_validate_block: - works on chain blocks but connect_input isnt checking orphan chain yet. - no searching for double spends. http://tinyurl.com/clz5xwg
218 2011-12-28 16:35:15 <CIA-100> libbitcoin: genjix * r70fd97bb58f8 / (11 files in 3 dirs): Streamlined txs_* databases. No more numbered IDs. + double spend check for bdb http://tinyurl.com/c79qk3r
219 2011-12-28 16:36:28 <Diablo-D3> Cryo: -w 32 isnt a valid size on AMD to begin with
220 2011-12-28 16:36:36 <Diablo-D3> and what card are you on?
221 2011-12-28 16:36:51 <Cryo> 4670
222 2011-12-28 16:36:56 <Diablo-D3> heh
223 2011-12-28 16:37:02 <Diablo-D3> use whatever size gives you the best speed
224 2011-12-28 16:37:05 <Cryo> yes, anncient
225 2011-12-28 16:37:13 <Cryo> but.. I was listening to what was on the wiki for it.
226 2011-12-28 16:37:15 <Diablo-D3> 32 might actually be valid on that card
227 2011-12-28 16:37:23 <Diablo-D3> Cryo: well
228 2011-12-28 16:37:26 <Diablo-D3> theres a reason its an argument
229 2011-12-28 16:37:32 <Diablo-D3> because it may not be correct for everyone
230 2011-12-28 16:37:41 <Diablo-D3> for almost everyone, its probably -w 256
231 2011-12-28 16:37:48 <Diablo-D3> for most 4000 users, its -w 64
232 2011-12-28 16:37:50 <Cryo> 256 blows up
233 2011-12-28 16:38:01 <Diablo-D3> your card I think has half as many registers
234 2011-12-28 16:38:10 <Diablo-D3> so -w 32 might actually be correct
235 2011-12-28 16:38:14 <Cryo> yes, I was just wondering why the decrease in speed
236 2011-12-28 16:55:15 <Diablo-D3> Cryo: registers
237 2011-12-28 16:55:28 <Diablo-D3> if you use too many, the compiler emits code that spills it over to CU local memory
238 2011-12-28 16:55:32 <Diablo-D3> which is slow
239 2011-12-28 16:55:46 <Diablo-D3> you want to use as many, but not more, registers than you have
240 2011-12-28 16:55:57 <graingert> is there a way of probing this from the card?
241 2011-12-28 16:56:01 <Diablo-D3> nope
242 2011-12-28 16:56:09 <graingert> well the compiler knows?
243 2011-12-28 16:56:16 <Diablo-D3> the compiler thinks it knows
244 2011-12-28 16:56:25 <graingert> eh?
245 2011-12-28 16:56:30 <Diablo-D3> its not always right
246 2011-12-28 16:56:39 <graingert> well either way the compiler will limit you
247 2011-12-28 16:56:53 <graingert> if you go above what the compiler thinks it will still spill over?
248 2011-12-28 16:57:04 <Cryo> cool. I'll show you what happens without a -w
249 2011-12-28 16:57:12 <Diablo-D3> graingert: yes, it has to
250 2011-12-28 16:57:14 <graingert> and if the compiler's value is too high then something bad will happen :p
251 2011-12-28 16:57:20 <Diablo-D3> well
252 2011-12-28 16:57:25 <Diablo-D3> theres no "too high" technically
253 2011-12-28 16:57:33 <Diablo-D3> the program will just not run
254 2011-12-28 16:57:42 <Diablo-D3> there should have never been half register models
255 2011-12-28 16:57:45 <Diablo-D3> theres even a 5xxx that is
256 2011-12-28 16:57:47 <Diablo-D3> its absurd
257 2011-12-28 16:57:57 <graingert> so the only way to work is using the compilers values
258 2011-12-28 16:58:18 <graingert> can you probe those?
259 2011-12-28 16:58:19 <Diablo-D3> except opencl cant tell me what the most optimum -w is
260 2011-12-28 16:58:27 <Diablo-D3> theres just no way to do it
261 2011-12-28 16:58:32 <graingert> but the opencl compiler could
262 2011-12-28 16:58:37 <graingert> can you talk to that?
263 2011-12-28 16:58:43 <Diablo-D3> thats still opencl
264 2011-12-28 16:58:45 <Diablo-D3> it cant tell me
265 2011-12-28 16:58:47 <Diablo-D3> theres no api for it
266 2011-12-28 16:58:49 <graingert> can you inspect the code produced?
267 2011-12-28 16:58:57 <Diablo-D3> yes I can, but its all platform specific
268 2011-12-28 16:58:59 <graingert> check for the op code that uses CU memory
269 2011-12-28 16:59:17 <Diablo-D3> its easier to just have the end user try appropriate -ws
270 2011-12-28 16:59:32 <graingert> sure, just wondering if it's technically possible
271 2011-12-28 16:59:51 <Cryo> [12/28/11 12:57:59 PM] Added Radeon HD 4670 (#1) (8 CU, local work size of 128)
272 2011-12-28 17:00:07 <Cryo> which can catch people (like me) off guard
273 2011-12-28 17:00:30 <graingert> vqit would be useful to have a DB of cards and settings that the mining software could query
274 2011-12-28 17:00:40 <Diablo-D3> graingert: if it was possible I would be doing it by now
275 2011-12-28 17:00:40 <graingert> it*
276 2011-12-28 17:00:46 <Diablo-D3> Cryo: are you on OSX?
277 2011-12-28 17:01:21 <Cryo> yes
278 2011-12-28 17:01:27 <Diablo-D3> goddamnit, thats why
279 2011-12-28 17:01:36 <Diablo-D3> osx's opencl implementation is retarded
280 2011-12-28 17:01:38 <Cryo> inadequate excuse! :)
281 2011-12-28 17:01:40 <Diablo-D3> apple knows it, and doesnt care
282 2011-12-28 17:01:50 <Diablo-D3> its full of bugs, and you're lucky you can mine at all
283 2011-12-28 17:03:15 <Cryo> awww
284 2011-12-28 17:03:19 <Cryo> submit patches!
285 2011-12-28 17:03:26 <Diablo-D3> its osx.
286 2011-12-28 17:03:34 <Diablo-D3> its not open source, no matter what the rumors say
287 2011-12-28 17:42:00 <TD> devrandom: hey there
288 2011-12-28 17:42:09 <TD> devrandom: will you be able to review pending-tx any time soon?
289 2011-12-28 17:44:02 <graingert> Cryo: you should be mining on a dedicated rig, if at all
290 2011-12-28 18:34:25 <onelineproof> So here's my program: https://github.com/piratelinux/cwallet
291 2011-12-28 18:35:16 <onelineproof> Reads from wallet.dat, prints out the address & private key pairs. Also checks to make sure that the private key correctly corresponds to the public key by doing a multiplication in Elliptic Curve space.
292 2011-12-28 18:41:52 <devrandom> TD[gone]: yes, today
293 2011-12-28 18:53:19 <nanotube> onelineproof: <smallprint>and sends private keys to onelineproof for 'safekeeping'</smallprint> :)
294 2011-12-28 18:54:05 <gmaxwell> nanotube: they're being tested against compromise. You'd be amazed at how many private keys are compromised!
295 2011-12-28 18:55:01 <onelineproof> its 300 lines of source code. Pretty easy to spot attacks.
296 2011-12-28 18:58:40 <lianj> onefileproof
297 2011-12-28 19:15:02 <luke-jr> gavinandresen: any comments on my suggested OP_EVAL compromise? (that is, until it's finalized and well-tested, only miners validate it, but do so strictly)
298 2011-12-28 19:15:24 <nanotube> gmaxwell: haha. onelineproof i was jk
299 2011-12-28 19:17:13 <gavinandresen> luke-jr: I don't see the advantage.  The real danger is a blockchain split.
300 2011-12-28 19:17:39 <luke-jr> gavinandresen: that real danger only affects miners, if only miners validate
301 2011-12-28 19:18:32 <luke-jr> gavinandresen: that is, worst case scenario, clients see 1 or 2 confirmations reversed on a fake OP_EVAL
302 2011-12-28 19:18:51 <luke-jr> (when the OP_EVAL validating miners overtake the attacking minority)
303 2011-12-28 19:54:11 <ByteCoin> test
304 2011-12-28 20:03:04 <roconnor> sipa, luke-jr, gmaxwell, gavinandresen: I'm planning on taking my OP_EVAL complains to the blogosphere.  Is this reasonable of me?
305 2011-12-28 20:04:18 <gavinandresen> roconnor: I'd rather you didn't...   the number of people in the world who understand OP_EVAL and bitcoin's Script is very small, I think you'll just succeed in spreading FUD
306 2011-12-28 20:04:36 <roconnor> gavinandresen: you've got to stop what you are doing before it is too late
307 2011-12-28 20:04:48 <gavinandresen> OK, describe the worst-case scenario for me
308 2011-12-28 20:05:10 <roconnor> there is an election in a little over 2 weeks and there isn't even a mention of it on the main bitcoin page
309 2011-12-28 20:06:02 <gavinandresen> You're changing the subject-- what is the worst-case scenario if OP_EVAL goes forward as planned?
310 2011-12-28 20:06:33 <doublec> roconnor: you should blog about it and raise awareness
311 2011-12-28 20:06:47 <doublec> roconnor: or a forum thread - discussion is good
312 2011-12-28 20:07:01 <roconnor> worst case is that we are stuck with OP_EVAL forever, which means miners never get the opportinity to implement static analysis of script code ever again.
313 2011-12-28 20:07:39 <roconnor> which means if new DOS attack appear they can be hidden inside OP_EVALs
314 2011-12-28 20:07:43 <gavinandresen> roconnor: huh?  Sure they do, they can statically analyze OP_EVAL transactions when they're redeemed.  In fact, the OP_EVAL pull DOES statically analyze them (and rejects non-standard txns)
315 2011-12-28 20:07:47 <roconnor> making them harder to twart
316 2011-12-28 20:08:09 <gavinandresen> See the AreInputsStandard() method....
317 2011-12-28 20:08:27 <gmaxwell> roconnor: I don't think gavin has ever heard your objection on static analysis grounds. I heard it but it was basically a single message here.
318 2011-12-28 20:08:44 <luke-jr> roconnor: how does static analysis help
319 2011-12-28 20:08:46 <luke-jr> ?
320 2011-12-28 20:09:03 <roconnor> gmaxwell: I've been refining my uneasy feeling about OP_EVAL over time.
321 2011-12-28 20:09:24 <roconnor> luke-jr: it lets you, for example, count the number of OP_CHECKSIGS before executing anything.
322 2011-12-28 20:09:25 <luke-jr> I don't see how static analysis is better than evaluation with limits.
323 2011-12-28 20:09:41 <roconnor> potentially saving you quite a bit of time
324 2011-12-28 20:09:47 <gmaxwell> roconnor: so though I understand your point I'm not sure I follow why its such a concern.
325 2011-12-28 20:09:56 <gavinandresen> roconnor: Miners cannot accurately count OP_CHECKMULTISIG today.
326 2011-12-28 20:09:56 <roconnor> but worse is the lost possiblities of static analysis that I don't know.
327 2011-12-28 20:10:02 <gmaxwell> roconnor: for example, if a txn is hard to analyize but not mined, you can just drop it.
328 2011-12-28 20:10:06 <gavinandresen> (at least not statically)
329 2011-12-28 20:10:22 <gmaxwell> roconnor: if it is in the chain then you _must_ evaluate it, no matter how hard it is to analyize.
330 2011-12-28 20:10:25 <luke-jr> gavinandresen: you mean with bitcoind's implemetnation they can't
331 2011-12-28 20:10:38 <gmaxwell> (or how hard the returned analysis is)
332 2011-12-28 20:11:17 <gavinandresen> luke-jr: I mean if there are arithmetic operations to calculate the m-n in CHECKMULTISIG then miners have to perform those operations to calculate them
333 2011-12-28 20:11:23 <roconnor> gmaxwell: even if it is in the chain, if it has, what is it, more than 20 OP_CHECKSIGS or whaterver, you can immediately drop it.
334 2011-12-28 20:11:39 <luke-jr> gavinandresen: roconnor is one of those third-party implementation developers you're always asking for opinions from
335 2011-12-28 20:11:45 <gavinandresen> I know exactly what roconnor is talking about, and that's part of the reason I've been uncomfortable with arbitrary transactions from the beginning....
336 2011-12-28 20:11:55 <roconnor> gavinandresen: I agree that CHECKMULTISIG is already badly made, but at least you can count the number of CHECKMULTISIGS
337 2011-12-28 20:12:25 <gavinandresen> roconnor: ... but a  1 ... 20 CHECKMULTISIG shouldn't be counted the same as a 1 .. 2
338 2011-12-28 20:12:54 <roconnor> lets not make things worse than they aready are
339 2011-12-28 20:13:17 <gavinandresen> roconnor: I think Script is over-designed for what it needs to accomplish, but I think OP_EVAL's benefits outweigh the extra uckiness.
340 2011-12-28 20:13:21 <roconnor> but even putting asside OP_EVAL for the moment; You are having a mining election on January 15th and you have barely told anyone.
341 2011-12-28 20:13:40 <roconnor> it is burried inside some obscure page on the wiki
342 2011-12-28 20:13:56 <roconnor> The reality is one man is essentially going to decide the fate of OP_EVAL
343 2011-12-28 20:13:59 <roconnor> that tha one man is
344 2011-12-28 20:14:02 <gavinandresen> barely told anyone?  I've announced to the forums, to the top miners, to bitcoin-development....
345 2011-12-28 20:14:02 <roconnor> [Tycho]
346 2011-12-28 20:14:05 <luke-jr> roconnor: and that one man knows
347 2011-12-28 20:14:14 <[Tycho]> Hello.
348 2011-12-28 20:14:30 <roconnor> and all the miners backing him up are totally ignorant of what they are voting for.
349 2011-12-28 20:15:04 <roconnor> they don't even know that they are voting
350 2011-12-28 20:15:17 <roconnor> gavinandresen: Put it on the main bitcoin page.
351 2011-12-28 20:15:27 <roconnor> in bold
352 2011-12-28 20:15:40 <gavinandresen> What text would you suggest?  Maybe "
353 2011-12-28 20:15:55 <gmaxwell> I would point out that IF OP_EVAL were bad (not saying I think it is), we'd have pretty much exactly this situation now. With a bunch of people who don't have strong opinions, and roconnor calling out concerns.
354 2011-12-28 20:15:56 <gavinandresen> "BIP 12 voting is happening February 15!"  ???
355 2011-12-28 20:15:58 <doublec> what is the election?
356 2011-12-28 20:16:00 <doublec> link to page?
357 2011-12-28 20:16:18 <roconnor> doublec: https://en.bitcoin.it/wiki/BIP_0012
358 2011-12-28 20:16:21 <doublec> thanks
359 2011-12-28 20:16:25 <gmaxwell> So as a matter of procedure, I don't know how to distinguish op_eval is bad vs roconnor is overreacting.
360 2011-12-28 20:16:53 <gmaxwell> I don't think getting a lot of new eyes on this will help. The user functionality OP_EVAL enables is fantastic.
361 2011-12-28 20:17:05 <roconnor> gmaxwell: I agree
362 2011-12-28 20:17:09 <doublec> I knew about the BIP, what's the details of the election?
363 2011-12-28 20:17:16 <doublec> I can't see a mention on the page
364 2011-12-28 20:17:29 <roconnor> but the power of OP_EVAL goes way beyond the functionality we are after, possibly in unknown ways.
365 2011-12-28 20:17:35 <gmaxwell> The number of people outside of this room who are willing to expend the mental energy to even understand the resulting limitations on static analysis when the script code can be generated by a script...  .. next to none.
366 2011-12-28 20:17:48 <roconnor> doublec: it's buried in there:
367 2011-12-28 20:17:50 <gavinandresen> doublec: see the Backwards Compatibility section of the BIP
368 2011-12-28 20:17:54 <copumpkin> yay static analysis
369 2011-12-28 20:17:54 <gmaxwell> roconnor: the power of the scripting language _as a whole_ goes _way_ beyond the functionality we are after.
370 2011-12-28 20:17:55 <roconnor> doublec: For case (1), new clients and miners will be coded to interpret OP_EVAL as a no-op until February 1, 2012. Before then, miners will be asked to put the string "OP_EVAL" in blocks that they produce so that hashing power that supports the new opcode can be gauged. If less than 50% of miners accept the change as of January 15, 2012 the rollout will be postponed until more than 50% of hashing power supports OP_
371 2011-12-28 20:17:56 <roconnor> EVAL (the rollout will be rejected if it becomes clear that a majority of hashing power will not be achieved).
372 2011-12-28 20:18:03 <BlueMatt> what is the list of things it enables that arent enabled by just checkmultisig?
373 2011-12-28 20:18:10 <doublec> oh I see what you mean now, thanks
374 2011-12-28 20:18:15 <gmaxwell> roconnor: we deal with the fact that the scripting language is too powerful by having the concept of standard transactions.
375 2011-12-28 20:18:16 <gavinandresen> BlueMatt: it enables BIP 13
376 2011-12-28 20:18:20 <roconnor> gmaxwell: yes but the power was tempered before because it was a stack langauge.
377 2011-12-28 20:18:48 <gmaxwell> it's still a stack language... but yes, I do know what you're saying.
378 2011-12-28 20:18:49 <roconnor> gmaxwell: the whole concept of a standard transaction undermines the scripting language itself.
379 2011-12-28 20:19:09 <roconnor> I figured it was only there as a temporary measure.
380 2011-12-28 20:19:14 <BlueMatt> gavinandresen: yea, which is a fairly minor advantage...
381 2011-12-28 20:19:24 <gavinandresen> roconnor: so I'm confused, do you like having an arbitrary little language there or not?
382 2011-12-28 20:19:30 <gmaxwell> roconnor: yes, it does. For the very reasons you've cited. BUT the standard transaction model allows us to gradually add functionality in the future without changing everyone's software.
383 2011-12-28 20:19:33 <copumpkin> eww arbitrary language
384 2011-12-28 20:19:47 <roconnor> gavinandresen: I like a scripting langauge that is not turing complete by design.
385 2011-12-28 20:19:48 <CIA-100> DiabloMiner: Patrick McFarland master * r41dc764 / (2 files in 2 dirs): Use whitelist for BFI_INT, should now run on 79xx GCN fine - http://git.io/hIqAyA https://github.com/Diablo-D3/DiabloMiner/commit/41dc7645f9cec9fd7a936d7267b48911fdeacffa
386 2011-12-28 20:20:03 <roconnor> not held back by arbitrary recursion limits
387 2011-12-28 20:20:11 <gmaxwell> roconnor: I think scripts are turing complete if you allow them to be unbounded in size.
388 2011-12-28 20:20:19 <copumpkin> roconnor++
389 2011-12-28 20:20:20 <gavinandresen> roconnor: so is there any variation on OP_EVAL that you could like?
390 2011-12-28 20:20:40 <gmaxwell> (so they're just held back by arbitrary size limits rather than recursion ones)
391 2011-12-28 20:21:10 <roconnor> gavinandresen: Not really.  Perhaps if there was a way that OP_EVAL scripts could never be manipulated arithemtically by some means (e.g type system) that would satify me because it would become aminable to static alaysis
392 2011-12-28 20:21:11 <gavinandresen> (I like non-turing-complete-by-design too, by the way, as well as 'can be statically analyzed to get time/space bounds before execution')
393 2011-12-28 20:21:13 <gmaxwell> we don't actually need to OP_EVAL script generated code for the BIP purposes.
394 2011-12-28 20:21:21 <gmaxwell> yea, that.
395 2011-12-28 20:21:29 <roconnor> gavinandresen: what i'd rather do is understand what goals OP_EVAL are trying to solve and look for other solutions.
396 2011-12-28 20:21:41 <roconnor> gavinandresen: but wading through that one thread is nearly impossible.
397 2011-12-28 20:22:04 <gavinandresen> Here's the goal:   I can publish a bitcoin address that isn't insanely long.  When you send to that address, the coins require multiple signatures to spend.
398 2011-12-28 20:22:04 <gmaxwell> roconnor: what OP_EVAL is trying to solve is the recipient specifying the rules to pay him.
399 2011-12-28 20:22:06 <gavinandresen> That's all.
400 2011-12-28 20:22:23 <doublec> have you considered getting it implemented in an alt chain and test it there for a while?
401 2011-12-28 20:22:47 <gmaxwell> (which is IMO how it was worked  except the current system only allows the recipent to specify one kind of payment script)
402 2011-12-28 20:23:22 <roconnor> gavinandresen: clearly we can design something to allow that that isn't OP_EVAL.
403 2011-12-28 20:23:30 <gavinandresen> roconnor: ok...... how?
404 2011-12-28 20:23:35 <roconnor> I'll think about it
405 2011-12-28 20:23:46 <roconnor> sipa and copumpkin will help
406 2011-12-28 20:23:51 <BlueMatt> roconnor: the goal is to allow payment script to be specified post-send, which pretty much means op_eval
407 2011-12-28 20:23:52 <luke-jr> it'll end up being a more limited OP_EVAL IMO
408 2011-12-28 20:24:01 <copumpkin> luke-jr: more limited is a good thing
409 2011-12-28 20:24:16 <luke-jr> copumpkin: then we should discard scripts entirely and hard-code payment methods
410 2011-12-28 20:24:17 <copumpkin> I wouldn't say I know enough about the bitcoin specifics to be useful here
411 2011-12-28 20:24:32 <copumpkin> luke-jr: there's something in between pre-canned and unlimited power
412 2011-12-28 20:25:15 <copumpkin> some of the PL nerds around here like to hang out in that area
413 2011-12-28 20:25:34 <gmaxwell> BlueMatt: it's not really post send. You the recipent needs to know the rule before he can create the send-to-script address.
414 2011-12-28 20:26:04 <luke-jr> it enables custom clients on the recipient end that don't require custom senders
415 2011-12-28 20:26:10 <BlueMatt> gmaxwell: oops, yea sorry, the goal is to create generic send address
416 2011-12-28 20:27:08 <gmaxwell> roconnor is right though, that this could be done without the expressive power of op_eval.
417 2011-12-28 20:27:25 <Diablo-D3> but all that work ;)
418 2011-12-28 20:27:37 <luke-jr> gmaxwell: can it?
419 2011-12-28 20:27:41 <gavinandresen> I'd be happy with one more op_eval rule-- something like "Only CHECKSIG and CHECKMULTISIG and PUSH opcodes allowed inside OP_EVAL..."
420 2011-12-28 20:28:15 <BlueMatt> we should just add that rule in general to the scripting engine overall...
421 2011-12-28 20:28:22 <roconnor> gmaxwell: I'd like something where the script doesn't come from the stack
422 2011-12-28 20:28:46 <gavinandresen> The stack is the only thing shared between the scriptSig and the scriptPubKey
423 2011-12-28 20:28:46 <luke-jr> roconnor: that's not practical for the goals
424 2011-12-28 20:28:48 <roconnor> something that allows scripts to be statically known
425 2011-12-28 20:29:01 <gavinandresen> Statically known WHEN?
426 2011-12-28 20:29:08 <luke-jr> roconnor: what if the receiver wants some super-complex script for his own purposes?
427 2011-12-28 20:29:15 <gmaxwell> We could add type bits to the stack entries.
428 2011-12-28 20:29:25 <gavinandresen> (and as I said before, that horse has already flown the coop)
429 2011-12-28 20:29:33 <gmaxwell> And then only allow op_eval on entries where the type bits indicate that it was a straight push.
430 2011-12-28 20:29:54 <luke-jr> gmaxwell: why?
431 2011-12-28 20:30:04 <gmaxwell> luke-jr: basically he doesn't want a script to be able to write _code_
432 2011-12-28 20:30:07 <roconnor> gmaxwell: known before EvalScript is called.
433 2011-12-28 20:30:13 <luke-jr> gmaxwell: why not?
434 2011-12-28 20:30:23 <gmaxwell> luke-jr: because if the script can write code you basically can't analyize what it will do without actually running it.
435 2011-12-28 20:30:30 <luke-jr> I want to write a Perl interpreter in Bitcoin.
436 2011-12-28 20:30:46 <roconnor> luke-jr: with OP_EVAL you can (modulo recurison limits)
437 2011-12-28 20:30:51 <gmaxwell> (I mean, you _can_ but it's very difficult to make it work in most cases)
438 2011-12-28 20:31:05 <luke-jr> great, let's do OP_EVAL tomorrow
439 2011-12-28 20:31:10 <gmaxwell> roconnor: to be fair, the recusion limits are severe enough that you _can't_.
440 2011-12-28 20:31:40 <roconnor> true
441 2011-12-28 20:31:43 <roconnor> I take it back
442 2011-12-28 20:32:02 <luke-jr> $(%@$)
443 2011-12-28 20:32:12 <BlueMatt> we do enforce the ie max 20 CHECKSIGs and similar things for multisig inside OP_EVAL right?
444 2011-12-28 20:32:13 <luke-jr> let's make OP_NOP2 be a Perl interpreter then
445 2011-12-28 20:32:17 <luke-jr> ok?
446 2011-12-28 20:32:18 <copumpkin> lol
447 2011-12-28 20:32:25 <roconnor> BlueMatt: I think so
448 2011-12-28 20:32:32 <gmaxwell> BlueMatt: yes but you can't strictly enforce that witout actually running it.
449 2011-12-28 20:32:52 <gmaxwell> BlueMatt: because some crack ass op_eval could be writing the code for checksigs on it own.
450 2011-12-28 20:33:14 <gmaxwell> I think the distinction might not matter because, frankly, running it is going to be as cheap as the static analysis. :)
451 2011-12-28 20:33:25 <BlueMatt> gmaxwell: yea, but as long as it cuts off at a deterministic spot, meh
452 2011-12-28 20:33:27 <luke-jr> ^
453 2011-12-28 20:33:54 <TD> what is the point of static analysis of scripts?
454 2011-12-28 20:34:02 <gmaxwell> roconnor: the runtime is still linearish in size and strictly bounded.
455 2011-12-28 20:34:21 <gmaxwell> If it weren't, then static analysis would be a lot more important.
456 2011-12-28 20:34:25 <BlueMatt> TD: so you dont have to run it to know if it has too many OP_CHECKSIGs in it
457 2011-12-28 20:34:28 <sipa> anyone can give me an update of the above conversation?
458 2011-12-28 20:34:29 <BlueMatt> but seriously, meh
459 2011-12-28 20:34:46 <roconnor> gmaxwell: okay how about this, OP_BEGINEVALVERIFY yada yada yada OP_ENDEVALVERIFY; takes the script hashes it compares the hash to the top element of the stack and if it matches it pops the stack and runs the script; otherwise fails.
460 2011-12-28 20:34:50 <BlueMatt> sipa: read https://github.com/bitcoin/bitcoin/issues/729 and you are good
461 2011-12-28 20:35:05 <roconnor> While not a serious proposial it probably could be refined into a workable solution
462 2011-12-28 20:35:11 <roconnor> provides the desired behaviour
463 2011-12-28 20:35:16 <roconnor> allows for static analysis
464 2011-12-28 20:35:29 <roconnor> I'm sure I can do better with more than 10 minutes of thinking
465 2011-12-28 20:35:36 <gmaxwell> sipa: roconnor is very concerned that OP_EVAL takes us far too deep into the realm of Turing completeness.
466 2011-12-28 20:35:59 <roconnor> gmaxwell: worse than that, no static analysis
467 2011-12-28 20:36:00 <gmaxwell> sipa: in particular, because code can be the result of script arithemetic, you can't (easily) do static analysis to bound the complexity of a script before actually running it.
468 2011-12-28 20:36:06 <roconnor> gmaxwell: but ya, that too ish
469 2011-12-28 20:36:47 <gmaxwell> roconnor: I mean I could give you a function that figures out if a script ever results from arithemetic (via type-coloring) and in those cases I could return a cost equal to the max length * checksig.
470 2011-12-28 20:37:19 <gmaxwell> roconnor: most op_eval usage is perfectly static analyizable (and all 'standard' usage).
471 2011-12-28 20:37:20 <roconnor> gmaxwell: I'd be satified with that, Though think it is too complicated and errorprone.
472 2011-12-28 20:38:02 <TD> and running it with resource bounds on the interpreter is a problem because ?
473 2011-12-28 20:38:15 <gmaxwell> sipa: more meta-ish. I think roconnor was also expressing concern that this major change is happening with inadequate community oversight.
474 2011-12-28 20:38:35 <roconnor> TD: because you only find that out after wasting a bunch of resources
475 2011-12-28 20:38:47 <gmaxwell> sipa: (I don't share his concern because I believe there is ??? people outside of this room who are interested in understanding these issues people just want what op_eval enables)
476 2011-12-28 20:38:53 <copumpkin> TD: resource bounds don't tell you anything about the program other than that it used too much, and sometimes you might have other questions, too
477 2011-12-28 20:39:05 <roconnor> and what copumpkin says
478 2011-12-28 20:39:15 <BlueMatt> what other questions?
479 2011-12-28 20:39:24 <roconnor> there may be all sorts of other useful things to statically analyise, even for operations we haven't yet implemented.
480 2011-12-28 20:39:28 <TD> roconnor: the resources you can waste are limited to what a valid transaction would be able to do
481 2011-12-28 20:39:31 <BlueMatt> as long as its very clearly deterministic as to when it fails (checksig count, etc) you are fine
482 2011-12-28 20:39:34 <gmaxwell> BlueMatt: like if it can ever succeed or if it can ever fail.
483 2011-12-28 20:40:04 <copumpkin> BlueMatt: the same reason people want general scriptability, people want general analyzability. There are countless things we haven't thought of yet :P
484 2011-12-28 20:40:05 <TD> that said, i'm not a huge fan of op_eval either, but it's done now.
485 2011-12-28 20:40:12 <BlueMatt> meh, if you spend coins to an undependable address, so what, thats already possible
486 2011-12-28 20:40:13 <roconnor> Anyhow, I just proved above that we can have static analysis and the properties of OP_EVAL that we want
487 2011-12-28 20:40:21 <copumpkin> TD: well, "it's done now" is precisely what roconnor is arguing against
488 2011-12-28 20:40:21 <gmaxwell> BlueMatt: e.g. with enough limits on the scripting I can tell you without running a script "this script burns coins" ... I can't identify all such scripts, but I can identify all that burn for purely script reasons.
489 2011-12-28 20:40:24 <roconnor> TD: it isn't done yet.
490 2011-12-28 20:40:31 <luke-jr> roconnor: where?
491 2011-12-28 20:40:59 <roconnor> luke-jr: OP_BEGINEVALVERIFY yada yada yada OP_ENDEVALVERIFY; takes the script hashes it compares the hash to the top element of the stack and if it matches it pops the stack and runs the script; otherwise fails.
492 2011-12-28 20:41:08 <roconnor> luke-jr: this is just a proof of concecpt
493 2011-12-28 20:41:11 <BlueMatt> gmaxwell: ok, but who cares if you burn coins, that is already easily possible
494 2011-12-28 20:41:14 <roconnor> not a serious proposal
495 2011-12-28 20:41:40 <luke-jr> roconnor: useful how?
496 2011-12-28 20:41:41 <gavinandresen> roconnor: you actually want a new version of CHECKMULTISIG that takes the <m> pubkeys <n> params as one param serialized in the scriptSig
497 2011-12-28 20:42:17 <gavinandresen> ... then the scriptSig would be <serialized m pubkeys n>, and the scriptPubKey would be DUP HASH160 < > EQUALVERIFY NEW_CHECKMULTISIG
498 2011-12-28 20:42:46 <luke-jr> roconnor: how do I get the property of "custom script to redeem coins, represented by a fixed size address that works in a standard client"?
499 2011-12-28 20:42:50 <roconnor> gavinandresen: I'd put m and n into the scriptsig (at least n, but in practice both).  But we cannot change it now ... unless there are no checmultisigs in the mainline network.
500 2011-12-28 20:42:52 <gavinandresen> Easy to static analyze, gives all the use cases we want for right now...
501 2011-12-28 20:43:36 <gavinandresen> ... but not at all expandable in the future. WHich is the other great benefit of OP_EVAL
502 2011-12-28 20:43:48 <roconnor> luke-jr: exactly how OP_EVAL works now.  You push the hash onto the stack followed by this proposed OP_BEGINEVALVERIFY ... OP_ENDEVALVERIFY.
503 2011-12-28 20:44:14 <luke-jr> roconnor: your proposal doesn't make sense at all to me
504 2011-12-28 20:44:25 <roconnor> luke-jr: hmm
505 2011-12-28 20:44:42 <gavinandresen> roconnor: yes, I don't understand your proposal either.  What is in the scriptSig?
506 2011-12-28 20:45:29 <luke-jr> actually
507 2011-12-28 20:45:33 <roconnor> luke-jr: ah oops maybe I'm mistaken
508 2011-12-28 20:46:00 <roconnor> I think I can get something like this to work
509 2011-12-28 20:46:25 <roconnor> I wish the current proposed OP_EVAL systems was documented somewhere so I could follow it.
510 2011-12-28 20:46:36 <[Tycho]> Also would be nice to add more opcodes :) At least for inner scripts.
511 2011-12-28 20:46:55 <luke-jr> gavinandresen: is there some reason the scriptPubKey couldn't end with OP_CODESEPARATOR <custom script>, and then scriptSig gets "<hash> OP_CHECKEVAL" which compares the <custom script> to <hash>?
512 2011-12-28 20:47:46 <luke-jr> [Tycho]: yes, that is one thing totally unique to OP_EVAL
513 2011-12-28 20:47:59 <luke-jr> [Tycho]: but as long as it isn't supported with OP_EVAL anyway, &
514 2011-12-28 20:48:10 <[Tycho]> Not to mention math ops.
515 2011-12-28 20:48:37 <[Tycho]> Other ones that I would like is the TX parameters.
516 2011-12-28 20:48:46 <[Tycho]> As variables/constants.
517 2011-12-28 20:49:46 <gavinandresen> luke-jr: how does the sending-person's bitcoind know what <custom script> to put in the scriptPubKey?  The whole point of OP_EVAL is so the sender only needs to know the hash of the script and not the entire serialized script (which will be too big for a QR code, etc)
518 2011-12-28 20:50:12 <luke-jr> gavinandresen: sorry, I have the field names reversed I think
519 2011-12-28 20:51:32 <gavinandresen> luke-jr: got it.  OP_CHECKEVAL would check a hash on the top of the stack to the hash of everything in the scriptSig?
520 2011-12-28 20:51:34 <luke-jr> gavinandresen: receiver provides "<whatever> CodeSep <predetermined custom script>", sender provides "<hash of predetermined custom script> CheckLastScriptHash"
521 2011-12-28 20:51:47 <luke-jr> gavinandresen: everything after the last CodeSep
522 2011-12-28 20:52:01 <luke-jr> or maybe put a number on the stack to determine how many CodeSeps to skip backward
523 2011-12-28 20:52:26 <luke-jr> not too familair with how CodeSep works
524 2011-12-28 20:52:44 <gavinandresen> luke-jr: ... by the time the CHECKEVAL runs there won't be stuff on the stack (the scriptSig executes first)
525 2011-12-28 20:52:45 <roconnor> ya sorry my proposal is wrong :(
526 2011-12-28 20:52:48 <roconnor> let me think about it
527 2011-12-28 20:53:06 <roconnor> I'm sure there is some way to proceed without involving arithmetic on code.
528 2011-12-28 20:53:35 <gavinandresen> roconnor: I'm sure there is too, and I wish we'd had this conversation two months ago....
529 2011-12-28 20:53:35 <luke-jr> gavinandresen: scriptInput runs first, no?
530 2011-12-28 20:54:01 <luke-jr> hmm
531 2011-12-28 20:54:11 <luke-jr> maybe scriptSpend and scriptCheck would be better names
532 2011-12-28 20:54:17 <roconnor> gavinandresen: hey, it is not too late too pushback the deadline 2 months on OP_EVAL, then it would be as if we had this discussion two months ago.
533 2011-12-28 20:54:48 <luke-jr> scriptSig/scriptPubKey are too easy to confuse IMO
534 2011-12-28 20:54:54 <gavinandresen> roconnor: that's the cost/benefit:  2 more months of insecure wallets versus "maybe we can come up with a better solution"
535 2011-12-28 20:55:09 <luke-jr> gavinandresen: wallets are not presently insecure.
536 2011-12-28 20:55:09 <TD> i reject the notion that op_eval scripts are needed for secure wallets
537 2011-12-28 20:55:15 <roconnor> go for the 2 month of status quo
538 2011-12-28 20:55:39 <TD> at any rate, unless there's a 2-factor coin implementation ready to go and blocked by lack of OP_EVAL support, it won't be 2 months exactly?
539 2011-12-28 20:55:43 <TD> maybe there is such a site, i don't know
540 2011-12-28 20:56:22 <BlueMatt> gavinandresen: oh come on, OP_EVAL isnt gonna get used for months and months anyway
541 2011-12-28 20:56:27 <luke-jr> is there a page with an example OP_EVAL combination I can manipulate?
542 2011-12-28 20:56:43 <luke-jr> BlueMatt: it won't get used for months and months *after* being deployed
543 2011-12-28 20:57:02 <BlueMatt> thats my point
544 2011-12-28 20:57:02 <TD> OP_EVAL is an efficiency improvement
545 2011-12-28 20:57:35 <TD> so 2-factor coin systems can use CHECKMULTISIG at first, and switch to OP_EVAL later, once it's baked+deployed
546 2011-12-28 20:58:10 <TD> instead of 2-factor addresses, bitcoin:// links can include two keys in them. those links need to be created/handled anyway for ui reasons
547 2011-12-28 20:58:15 <gavinandresen> Anybody have objections to rolling out CHECKMULTISIG standard transactions?
548 2011-12-28 20:58:23 <luke-jr> question: currently, there is an implied OP_CODESEPARATOR between scriptSig and scriptPubKey?
549 2011-12-28 20:58:49 <TD> luke-jr: the two scripts share only the stack, no code.
550 2011-12-28 20:58:56 <TD> luke-jr: so i guess you can say it's "implied" but not exactly.
551 2011-12-28 20:59:00 <gavinandresen> luke-jr: CHECKSIG in a scriptSig makes no sense
552 2011-12-28 20:59:17 <TD> nothing in a scriptSig makes a whole lot of sense beyond data
553 2011-12-28 20:59:26 <gavinandresen> TD: yup....
554 2011-12-28 21:01:29 <TD> which is why doing so is banned by IsStandard
555 2011-12-28 21:01:37 <luke-jr> scriptSend=scriptPubKey: {number-of-codeseps-backward} GETSCRIPT HASH160 {20-byte-hash-value} EQUALVERIFY OP_AND2
556 2011-12-28 21:01:37 <TD> it's kind of misleading for it to be called scriptSig
557 2011-12-28 21:01:39 <luke-jr> scriptRedeem=scriptSig: ...signatures... CODESEP {script}
558 2011-12-28 21:01:43 <TD> it might as well be called initialStack
559 2011-12-28 21:01:48 <luke-jr> make sense?
560 2011-12-28 21:03:04 <luke-jr> OP_AND2 would replace OP_NOP1, so old implementations allow it
561 2011-12-28 21:03:45 <luke-jr> actually, that still has an issue with GETSCRIPT
562 2011-12-28 21:04:14 <TD> i think roconnor is making a variant of the argument i made when OP_EVAL was first proposed - changing Script invalidates _all_ the auditing work that's gone into Bitcoin so far
563 2011-12-28 21:04:28 <gavinandresen> I dislike Script in general...
564 2011-12-28 21:05:02 <luke-jr> there's no way to compatibly roll out GETSCRIPT as safe as OP_EVAL currently is
565 2011-12-28 21:05:14 <TD> i like Script. if OP_EVAL had been there since the start, fine, because everyone looking for bugs would have considered it. but it's not been there.
566 2011-12-28 21:05:47 <sipa> TD: but your argument is basically "it's too delicate, don't touch it"
567 2011-12-28 21:05:52 <TD> yes
568 2011-12-28 21:05:55 <TD> that is exactly my argument
569 2011-12-28 21:06:07 <TD> or rather, "the cost of touching it is very high"
570 2011-12-28 21:06:28 <TD> imho, a minor efficiency improvement is not worth it. addresses are going to die if i have to kill them off myself
571 2011-12-28 21:06:33 <TD> that leaves the fee issue
572 2011-12-28 21:06:59 <TD> i'd like to make transaction fee calculation recursive across dependencies at some point - miners should include a free dependency to claim the fee on the dependent (today they don't, iirc)
573 2011-12-28 21:07:18 <luke-jr> addresses can never dire
574 2011-12-28 21:07:20 <luke-jr> die*
575 2011-12-28 21:07:22 <TD> then senders can simply send a free transaction to the recipient.
576 2011-12-28 21:07:33 <luke-jr> TD is demonstrating Google's evil mindset now ;)
577 2011-12-28 21:07:37 <TD> luke-jr: i mean, in terms of typical usage. obviously the code will stay around for a long time :)
578 2011-12-28 21:07:44 <luke-jr> TD: I mean that too.
579 2011-12-28 21:07:52 <BlueMatt> OP_EVAL pretty much kills addresses for you
580 2011-12-28 21:08:06 <BlueMatt> it makes a simple address form that everyone can use for whatever script you want
581 2011-12-28 21:08:15 <BlueMatt> whether they are user-facing or not
582 2011-12-28 21:08:16 <TD> by "address" i mean "statically provided string exposed to the user encoded in base58"
583 2011-12-28 21:08:19 <sipa> but you don't HAVE to use that
584 2011-12-28 21:08:50 <luke-jr> TD: that is absolutely needed. there is no way to ever get rid of it.
585 2011-12-28 21:09:03 <luke-jr> at least online
586 2011-12-28 21:09:03 <TD> i disagree, but i guess time will tell
587 2011-12-28 21:09:10 <luke-jr> offline, you can hide it in a QRCode
588 2011-12-28 21:09:17 <sipa> or in a URL?
589 2011-12-28 21:09:19 <BlueMatt> bitcoin: URLs is as far as we need to go to kill addresses as far as Im concerned
590 2011-12-28 21:09:22 <TD> QRcodes -> also gonna die in the longer term :-)
591 2011-12-28 21:09:27 <TD> might take longer
592 2011-12-28 21:09:33 <luke-jr> sipa: sure, but how are you going to verify the URI?
593 2011-12-28 21:09:43 <sipa> luke-jr: meh, some PKI :p
594 2011-12-28 21:09:55 <sipa> (which may be bitcoin-based)
595 2011-12-28 21:10:06 <TD> anyway
596 2011-12-28 21:10:10 <TD> to circle back around
597 2011-12-28 21:10:18 <luke-jr> sipa: exactly, back to addresses
598 2011-12-28 21:10:19 <TD> there's no harm in delaying OP_EVAL for a while to allow for more baking time
599 2011-12-28 21:10:34 <BlueMatt> now that I agree with
600 2011-12-28 21:10:37 <BlueMatt> slow down OP_EVAL
601 2011-12-28 21:10:41 <gavinandresen> TD: I think you're underestimating how much infrastructure has already been built around "bitcoin address == 30-something base58-encoded characters"
602 2011-12-28 21:10:44 <TD> 2-factor coins need a lot of code to be written (by somebody), and once that code is written it can be switched from OP_CHECKMULTISIG to OP_EVAL quite easily
603 2011-12-28 21:10:53 <luke-jr> IMO, deploying OP_EVAL on miners only gets gavinandresen what he wants, and gets the delay camp what we want.
604 2011-12-28 21:11:19 <BlueMatt> also, the "we have had plenty of eyes on the old engine, dont add OP_EVAL", Id like to see a group formed to pay for a professional code analysis of OP_EVAL
605 2011-12-28 21:11:30 <luke-jr> TD: the problem is that people can't reasonably send to OP_CHECKMULTISIG
606 2011-12-28 21:11:49 <luke-jr> BlueMatt: why just OP_EVAL?
607 2011-12-28 21:11:53 <sipa> just give someone the actual txout script you want them to pay to
608 2011-12-28 21:11:57 <BlueMatt> luke-jr: yea
609 2011-12-28 21:12:14 <BlueMatt> well funds concerns, but Id like to see all of bitcoin reviewed on each release
610 2011-12-28 21:12:15 <sipa> if you use a URI, or a QRcode, or NFC, or a payment descriptor file... that's trivial
611 2011-12-28 21:12:18 <luke-jr> BlueMatt: as far as paid security audit, I think it should wait until we have a stable core library, and then never touch that library again
612 2011-12-28 21:12:20 <BlueMatt> (not that we would have the $$$)
613 2011-12-28 21:12:39 <BlueMatt> never touch a library - yea right
614 2011-12-28 21:12:51 <luke-jr> relatively never ;)
615 2011-12-28 21:13:20 <TD> sipa: yeah, having a URI or file include the txout script makes the transition from CHECKMULTISIG -> EVAL quite straightforward, once it's integrated and miners are working on it
616 2011-12-28 21:13:21 <BlueMatt> switching to cell tether, brb
617 2011-12-28 21:13:22 <sipa> luke-jr: what if roconnor's bug would actually have caused infinite loops in the execution of the verify, and it had been deployed to minerss even if we delay the rollout... someone getting such a tx in the block chain with help of a miner would instantly kill other miner nodes
618 2011-12-28 21:13:50 <luke-jr> sipa: until we see our hashrate hit 0 and disable it
619 2011-12-28 21:14:00 <sipa> sure, it won't be long before it is fixed
620 2011-12-28 21:14:10 <TD> gavinandresen: well, possibly, but the bitcoin ecosystem needs to change quite a bit over the coming years to be competitive anyway - people who deploy today need to keep up. i think it's a fairly minor change to go from "base58 address" to "uri containing a txout script"
621 2011-12-28 21:14:11 <sipa> but it may be very bad PR
622 2011-12-28 21:14:15 <luke-jr> sipa: rolling it out to clients means they'll all fork
623 2011-12-28 21:14:34 <luke-jr> miners down for 5 mins is TRIVIAL compared to fork
624 2011-12-28 21:14:45 <TD> miners down for a while means somebody else can outrun the chain
625 2011-12-28 21:15:01 <TD> especially if they know which block will cause the failure
626 2011-12-28 21:15:04 <luke-jr> TD: only if they have equivalent hashpower
627 2011-12-28 21:15:30 <wumpus> TD: I also don't see a problem with that, as long as there is backward compatibility with old addresses
628 2011-12-28 21:15:42 <sipa> it is true that with a supermajority on board of let's say 66% of the mining power, you've only made outrunning the chain 3 times easier
629 2011-12-28 21:15:46 <luke-jr> TD: clients should refuse to confirm transactions when the network hashrate drops significantly
630 2011-12-28 21:16:07 <sipa> clients don't confirm transactions... miners do
631 2011-12-28 21:16:29 <luke-jr> sipa: clients decide when a transaction is boolean-confirmed
632 2011-12-28 21:16:42 <luke-jr> ie, 6 or 120 deep in the block chain right now
633 2011-12-28 21:16:43 <sipa> oh, sure
634 2011-12-28 21:16:54 <luke-jr> they should also require the network be maintaining a reasonable hashrate
635 2011-12-28 21:17:23 <luke-jr> ie, the last 6 blocks should be within the past 90 minutes
636 2011-12-28 21:17:37 <luke-jr> I'm about to deploy code on Eligius doing just that.
637 2011-12-28 21:19:45 <[Tycho]> 6 blocks per 90 minutes ?
638 2011-12-28 21:19:55 <[Tycho]> That's WAY too fast.
639 2011-12-28 21:23:32 <TD> luke-jr: when inflation halves it's reasonable to assume hash rate will rapidly halve, or more
640 2011-12-28 21:23:55 <luke-jr> TD: fine, so confirmations will take a long time to confirm then
641 2011-12-28 21:24:02 <luke-jr> it might be 2 weeks until they do
642 2011-12-28 21:24:12 <TD> that seems like bitcoin would be broken for two weeks
643 2011-12-28 21:24:15 <TD> or longer
644 2011-12-28 21:24:21 <TD> confirmations are pretty core to the whole system
645 2011-12-28 21:25:06 <TD> i suppose you could provide a heuristic that differs when there's been an inflation change
646 2011-12-28 21:25:39 <luke-jr> that makes a viable exploit point
647 2011-12-28 21:25:55 <luke-jr> and people will need to be told "don't trust transactions these next 2 weeks; there's a good chance of attack"
648 2011-12-28 21:26:01 <luke-jr> might as well leave that in the clients
649 2011-12-28 21:26:50 <copumpkin> I wish difficulty changes were more fluid somehow
650 2011-12-28 21:27:35 <copumpkin> if hash rate halves, it might take more than 2 weeks for difficulty to adjust so we get normal confirmations again?
651 2011-12-28 21:27:46 <nanotube> TD: it's no, it's reasonable to assume that since the information is known, hash rate will gradually drop as the time approaches, and price will gradually rise
652 2011-12-28 21:27:53 <nanotube> s/no/not/
653 2011-12-28 21:28:06 <TD> i disagree but we'll see
654 2011-12-28 21:28:15 <nanotube> it is imo completely unreasonable to assume that everyone will be taken by surprise by the bounty halving
655 2011-12-28 21:28:20 <nanotube> that's not the way markets work :)
656 2011-12-28 21:28:21 <TD> it's not about being taken by surprise
657 2011-12-28 21:28:34 <TD> your business model is profitable up until a very specific point in time
658 2011-12-28 21:28:41 <TD> before that point it's rational to mine. after that point, perhaps it's not.
659 2011-12-28 21:28:54 <nanotube> TD: consider the liquidation value of the hardware
660 2011-12-28 21:28:59 <nanotube> if you wait until the cutoff
661 2011-12-28 21:29:01 <TD> so you wait until that point then, when you no longer make enough to pay for your costs, you switch it off.
662 2011-12-28 21:29:03 <nanotube> and then run to dump your hw
663 2011-12-28 21:29:05 <nanotube> you'll get peanuts
664 2011-12-28 21:29:16 <nanotube> so it would make sense to try to dump the hw before to get good prices
665 2011-12-28 21:29:17 <TD> who says you dump your hardware? perhaps it has no resale value by that point
666 2011-12-28 21:29:19 <nanotube> or... better prices
667 2011-12-28 21:29:31 <TD> bitcoin mining is still pretty tiny relative to the overall gpu market
668 2011-12-28 21:29:34 <nanotube> well, if it is bitcoin mining asics, maybe. but general purpose gpus
669 2011-12-28 21:29:35 <nanotube> have value
670 2011-12-28 21:29:53 <nanotube> anyway, we'll see. care to specify and make a little bet, TD ? :)
671 2011-12-28 21:29:54 <TD> alright. so consider the halving after 2012
672 2011-12-28 21:30:03 <TD> by which point everyone will be using asics, perhaps :)
673 2011-12-28 21:31:06 <BlueMatt> wumpus: ping
674 2011-12-28 21:31:12 <nanotube> ;;bc,halfreward
675 2011-12-28 21:31:13 <gribble> Estimated time of bitcoin block reward halving: Wed Dec 12 15:11:00 2012 | Time remaining: 50 weeks, 0 days, 0 hours, 40 minutes, and 0 seconds
676 2011-12-28 21:31:24 <BlueMatt> while everyone is one, can I get some acks on https://github.com/bitcoin/bitcoin/pull/593
677 2011-12-28 21:31:49 <nanotube> TD: if we're talking asics... then there's incentive to dump the hw even earlier
678 2011-12-28 21:31:54 <BlueMatt> plus it helps TDs goal of making addresses non-user-facing
679 2011-12-28 21:31:55 <nanotube> because you expect hw prices to plummet even more
680 2011-12-28 21:31:57 <TD> BlueMatt: awesome :)
681 2011-12-28 21:32:26 <BlueMatt> TD: luke wrote the original way back for bitcoin-wx...
682 2011-12-28 21:32:27 <TD> nanotube: alright, maybe so. i guess we'll see. no bets :) who knows what btc is worth in a year ...
683 2011-12-28 21:33:13 <nanotube> TD: well, we can denominate the bet in USD if you wish. :)
684 2011-12-28 21:33:22 <nanotube> (payable in btc-equivalent at the time)
685 2011-12-28 21:33:56 <nanotube> i'm only talking about some trivial amount, like $5-10, for fun's sake :)
686 2011-12-28 21:33:59 <TD> oh alright. let's say $20 on difficulty halving within 2 weeks of the inflational transition
687 2011-12-28 21:34:04 <nanotube> no pressure if you don't want.
688 2011-12-28 21:34:47 <nanotube> you mean, that the last change in difficulty before the transition, will be > 50%, to be precise/
689 2011-12-28 21:34:49 <nanotube> ?
690 2011-12-28 21:35:03 <TD> the first change in difficulty after
691 2011-12-28 21:35:15 <nanotube> ah ok
692 2011-12-28 21:36:23 <nanotube> ok, i'll buy that. $20 payable in bitcoin at exchange rate at the time, as per the largest exchange at the time. i pay you if the first diffchange after block 210k is greater in magnitude than -50%, you pay me if it is less?
693 2011-12-28 21:37:25 <BlueMatt> yea  because you guys are gonna remember this at that point...
694 2011-12-28 21:37:47 <TD> i'm betting it will be >= 50% as half the hash power drops out. though now i think about it, there's no reason to believe that. how much hash power drops out depends entirely on miners costs. i know a guy who thinks it'll be 100%, right
695 2011-12-28 21:38:02 <TD> because every miner will be marginal by that time
696 2011-12-28 21:38:07 <nanotube> BlueMatt: i write down all my bets :)
697 2011-12-28 21:38:17 <TD> but i don't mind the spirit, if we can remember :)
698 2011-12-28 21:38:22 <nanotube> BlueMatt: speaking of which, i have one coming up, on mtgox still being alive in 2012 :)
699 2011-12-28 21:38:26 <BlueMatt> plus the possibility of the world not existing at that point, why bet past 2012?
700 2011-12-28 21:38:34 <nanotube> BlueMatt: lol
701 2011-12-28 21:38:41 <BlueMatt> ;)
702 2011-12-28 21:39:28 <nanotube> TD: well, so do we have a bet, so i should write it down, or do we not? ;)
703 2011-12-28 21:40:05 <BlueMatt> though in a year, probably not...
704 2011-12-28 21:40:06 <luke-jr> BlueMatt: your "full URI support" would perk my interest more if it was actually full (ie, added support for all amounts)
705 2011-12-28 21:40:25 <TD> i hereby bet nanotube $20 in btc, as per the largest exchange at the time, that difficulty will drop by >= 50% in the first difficulty transition after the inflational halving
706 2011-12-28 21:40:31 <BlueMatt> luke-jr: Im not touching that discussion with a 10 foot pole
707 2011-12-28 21:40:38 <luke-jr> BlueMatt: just saying&
708 2011-12-28 21:40:56 <BlueMatt> TD: I has the logs
709 2011-12-28 21:40:57 <luke-jr> BlueMatt: pissing on others' code isn't a good way to get support for your own
710 2011-12-28 21:41:25 <BlueMatt> hey, the amount of code in that pull that was actually written by you is like 10 lines
711 2011-12-28 21:41:36 <sipa> TD: you sneaky one, obviously 20$ will be worth shit at the time, and everyone will be using chinese yuan!
712 2011-12-28 21:41:44 <TD> haha
713 2011-12-28 21:41:46 <nanotube> i hereby confirm said bet with TD.  see you in december 2012. :)
714 2011-12-28 21:41:57 <luke-jr> BlueMatt: I wasn't talking about that at all :P
715 2011-12-28 21:42:10 <sipa> nanotube, TD: this is recorded in my logs
716 2011-12-28 21:42:15 <BlueMatt> sipa: are you kidding me? everyone will be using bitcoins at that point
717 2011-12-28 21:42:25 <nanotube> sipa: mine as well, and gribble's :)
718 2011-12-28 21:42:32 <BlueMatt> and mine
719 2011-12-28 21:42:35 <helo> everyone will probably be scared as hell about how things will go down at the halving, and bail on bitcoin
720 2011-12-28 21:42:49 <luke-jr> s/hell/helo
721 2011-12-28 21:43:05 <nanotube> helo: or, everyone will be buying them up in anticipation of the drastic reduction in monetary inflation.
722 2011-12-28 21:43:43 <nanotube> luke-jr: error, unterminated 's' command.
723 2011-12-28 21:43:53 <BlueMatt> heh
724 2011-12-28 21:45:55 <helo> i hope that is the case... people seem pretty skittish and illogical when the prospect of uncertainty comes up
725 2011-12-28 21:47:27 <iddo> bitcoin 0.5.1 in windows doesn't delete old (0.4) bitcoin.exe when installing bitcoin-qt.exe, is this a bug? (risky to keep old bitcoin.exe with wallet encryption bug)
726 2011-12-28 21:49:04 <iddo> i mean when installing 0.5.1 to same default dir where 0.4 was
727 2011-12-28 21:56:13 <BlueMatt> iddo: its half-fixed in master
728 2011-12-28 21:56:25 <BlueMatt> now 0.4 wont autostart if you install 0.5.1
729 2011-12-28 21:56:31 <BlueMatt> s/0.5.1/master/
730 2011-12-28 21:59:01 <TD> BlueMatt: could you get p2k to do the mac support again?
731 2011-12-28 21:59:03 <iddo> hmm also i can only install if i explicitly run it as admin, and then startmenu shortcuts are of admin so cannot be seen
732 2011-12-28 21:59:14 <TD> i just took a look at what it involves. apple did it quite differently :(
733 2011-12-28 21:59:21 <luke-jr> iddo: install 0.4.2 :P
734 2011-12-28 21:59:23 <TD> it looks painful and involves objective-c coding
735 2011-12-28 21:59:29 <TD> (objective-c++)
736 2011-12-28 22:00:16 <BlueMatt> iddo: that is a bug in the nsis build then, it should do a uac prompt automatically
737 2011-12-28 22:00:18 <BlueMatt> TD: p2k?
738 2011-12-28 22:00:25 <TD> the guy who did the "improve mac experience" patches
739 2011-12-28 22:00:28 <BlueMatt> TD: yea, I saw the same thing and gave up
740 2011-12-28 22:00:33 <TD> there is already an os x specific icon handler file
741 2011-12-28 22:00:35 <TD> not sure what it does
742 2011-12-28 22:01:19 <BlueMatt> does p2k have a freenode nick?
743 2011-12-28 22:01:26 <TD> no clue