1 2011-12-02 00:34:17 <Lunaqus> how do you start a pool?
  2 2011-12-02 00:34:41 <gmaxwell> open a faucet and put something under it to catch the water?
  3 2011-12-02 00:34:42 <gmaxwell> ;)
  4 2011-12-02 00:34:54 <Lunaqus> your funny :P
  5 2011-12-02 00:35:04 <gmaxwell> My funny what?
  6 2011-12-02 00:35:13 <Lunaqus> lol
  7 2011-12-02 00:35:23 <Lunaqus> how do I start a mining pool please?
  8 2011-12-02 00:35:24 <gmaxwell> In any case, you use software like pushpoold.
  9 2011-12-02 00:35:43 <gmaxwell> And you write a bunch of interface software to handle doing payouts to people.
 10 2011-12-02 00:39:00 <CIA-100> bitcoinjs/bitcoinjs-lib: Stefan Thomas master * rbbd8680 / build/bitcoinjs-min.js : Build updated. - http://git.io/v_S6HQ https://github.com/bitcoinjs/bitcoinjs-lib/commit/bbd86803e664d178470969014bc9269f76477592
 11 2011-12-02 00:58:02 <ByteCoin> ;;seen gavinandresen
 12 2011-12-02 00:58:03 <gribble> gavinandresen was last seen in #bitcoin-dev 3 hours, 38 minutes, and 16 seconds ago: <gavinandresen> osmosis: I've got some twisted code here: https://github.com/gavinandresen/Bitcoin-protocol-test-harness
 13 2011-12-02 00:58:22 <ByteCoin> ping gavin?
 14 2011-12-02 01:11:42 <luke-jr> Lunaqus: why bother?
 15 2011-12-02 01:12:17 <SomeoneWeird> ^^
 16 2011-12-02 01:41:17 <phantomcircuit> slush, hey
 17 2011-12-02 01:43:07 <slush> phantomcircuit: yes
 18 2011-12-02 01:43:24 <phantomcircuit> slush, could you add intersango to sierrachart?
 19 2011-12-02 01:43:35 <slush> is intersango on bitcoincharts?
 20 2011-12-02 01:44:33 <slush> phantomcircuit: ^
 21 2011-12-02 01:45:16 <phantomcircuit> yes
 22 2011-12-02 01:45:26 <slush> phantomcircuit: then it's in the sierra already
 23 2011-12-02 01:45:30 <slush> see -s parameter
 24 2011-12-02 01:45:40 <phantomcircuit> ah
 25 2011-12-02 01:45:52 <phantomcircuit> neat
 26 2011-12-02 01:47:44 <slush> phantomcircuit: works?
 27 2011-12-02 01:48:00 <slush> phantomcircuit: to be honest, I didn't test it for the last release. But it should work without problems
 28 2011-12-02 01:50:25 <ByteCoin> Does anyone know where I could find the proposed standard scripts for multisignature transactions please?
 29 2011-12-02 01:53:03 <etotheipi_> ByteCoin, I JUST posted to the end of the BIP 0010 thread ...
 30 2011-12-02 01:53:13 <phantomcircuit> slush, no idea im on a linux netbook w/o wine
 31 2011-12-02 01:53:26 <etotheipi_> https://bitcointalk.org/index.php?topic=48215.0, https://en.bitcoin.it/wiki/BIP_0011
 32 2011-12-02 01:53:38 <etotheipi_> (err... BIP 0011 thread)
 33 2011-12-02 01:54:30 <etotheipi_> ByteCoin, a few posts from the bottom of the thread, I laid exactly how I believe those multi-sig txs to work, and so far no one told me it's wrong
 34 2011-12-02 01:54:49 <etotheipi_> amusingly, I actually based that on a thread I read *from you* back in April
 35 2011-12-02 01:56:01 <ByteCoin> I believe your multisignature transactions are unlikely to be correct as they do not deal with the hashes of the public keys.... thanks though..
 36 2011-12-02 01:56:19 <etotheipi_> ByteCoin, what do you mean?
 37 2011-12-02 01:56:28 <ByteCoin> There was a discussion document .. I've lost it.
 38 2011-12-02 01:56:38 <etotheipi_> the proposed standard ONLY includes public-key Multi-sig txs
 39 2011-12-02 01:56:44 <etotheipi_> no public key hashes
 40 2011-12-02 01:57:00 <ByteCoin> Oh! That's a change from what was being discussed before
 41 2011-12-02 01:57:26 <ByteCoin> Theymos, do YOU know what the standard multisig transactions scripts are?
 42 2011-12-02 01:57:33 <btginsb> anyone have experience with mtgox api?
 43 2011-12-02 01:57:35 <etotheipi_> there's a bunch of multi-sig transactions I extracted from the testnet that do what you're talking about (uses the hashes, and checks them)... I can link you to them if you want to see them, but they won't be part of the std
 44 2011-12-02 01:57:43 <etotheipi_> they're big as hell
 45 2011-12-02 01:57:46 <theymos> luke-jr: No, I don't think it should be backported. In case there's something terribly wrong with the anti-DoS measures, it'd be nice to not have the entire network fail.
 46 2011-12-02 01:58:01 <theymos> ByteCoin: checkmultisig.
 47 2011-12-02 01:59:09 <btginsb> can anyone help with the mtgox api?
 48 2011-12-02 02:01:24 <luke-jr> theymos: https://bitcointalk.org/index.php?topic=53505.0
 49 2011-12-02 02:01:33 <luke-jr> btginsb: try #Mtgox maybe
 50 2011-12-02 02:01:41 <btginsb> its dead over there
 51 2011-12-02 02:01:48 <btginsb> their support sucks
 52 2011-12-02 02:02:30 <btginsb> i havent changed any of my code, yet i cant seem to access the api. tried changing accounts, computers, even tethered to my phone to use a diff IP
 53 2011-12-02 02:02:56 <luke-jr> btginsb: give em a little more time, they're just waking up
 54 2011-12-02 02:03:21 <luke-jr> (well ok, it's actually about noon&)
 55 2011-12-02 02:08:59 <phantomcircuit> btginsb, their order listing api was 100% broken for open orders earlier
 56 2011-12-02 02:09:03 <phantomcircuit> but i think they fixed it?
 57 2011-12-02 02:09:33 <etotheipi_> If anyone else is interested, I extracted all the nonstd scripts from the testnet:  https://gist.github.com/1329788, and also laid out the exact stack-state at each opcode evaluation (could be educational):  https://gist.github.com/1421550
 58 2011-12-02 02:10:14 <btginsb> well the problem is the trading api for me
 59 2011-12-02 02:10:30 <phantomcircuit> id suspect they broke lots of stuff
 60 2011-12-02 02:10:42 <etotheipi_> all those scripts check public key *hashes* in the multi-sig... but none of them will be standard as far as I know.
 61 2011-12-02 02:10:47 <upb> no worries, atleast we have the cool new ui design
 62 2011-12-02 02:12:10 <phantomcircuit> lold
 63 2011-12-02 02:12:53 <theymos> etotheipi_: Those TOALTSTACK ones are IIRC smaller than checkmultisig for multi-sig address transactions.
 64 2011-12-02 02:14:58 <etotheipi_> theymos, do you mean less bytes-per-script?    I was more concerned with actual opcodes-per-script because I'm concerned about complexity
 65 2011-12-02 02:15:45 <theymos> Yes, fewer bytes. I'm not sure that a checkmultisig solution would have fewer opcodes, either.
 66 2011-12-02 02:16:17 <etotheipi_> even if you count 20-opcodes-per-OP_CHECKMULTISIG I think it's less
 67 2011-12-02 02:16:58 <gmaxwell> etotheipi_: I wouldn't worry so much about the opcodes as much as the signature/hash operations.
 68 2011-12-02 02:17:22 <etotheipi_> the OP_CHECKMULTISIG is remarkably simple... you just dump the public keys and sigs in there... the ones that I linked from testnet are 40+ OPCODES
 69 2011-12-02 02:17:59 <gmaxwell> Presumably in some future where the computing time of evaluting scripts mattered someone could write something to JIT scripts into native code... and require higher fees on unusual scripts that can't be jitted or don't match a previously cached jit template.
 70 2011-12-02 02:18:07 <etotheipi_> are the scripts that I posted evaluated more efficiently than the OP_CHECKMULTISIG scripts?
 71 2011-12-02 02:18:08 <gmaxwell> 'simple'
 72 2011-12-02 02:18:32 <gmaxwell> You're ignoring the several million cpu cycles required by carefully tuned code to validate a signature.
 73 2011-12-02 02:19:01 <theymos> etotheipi_: checkmultisig is clearly better for public keys, but it's hard to use it with addresses.
 74 2011-12-02 02:19:14 <etotheipi_> how am I ignoring it?   I recognize that's slow... but no matter how you construct the 2-of-3 tx, you're going to have to verify 2 or 3 signatures
 75 2011-12-02 02:19:58 <gmaxwell> etotheipi_: because the rest of the opcodes are ~irrelevant compared to that (assuming a sufficiently efficient implementation)
 76 2011-12-02 02:20:49 <etotheipi_> gmaxwell, I see what's going on here... I was concerned more about the max-opcodes-per-block limit... not the evaluation speed:  I figured the evaluation speed would be identical because both script types have the same number of sigs to verify
 77 2011-12-02 02:21:12 <etotheipi_> ...unless the implementations are different
 78 2011-12-02 02:21:15 <gmaxwell> theymos: you really shouldn't be using it with addresses in any case. If someone didn't give you the exact transaction template they probably won't reconize it as belonging to them.
 79 2011-12-02 02:21:35 <gmaxwell> etotheipi_: oh. I'm sorry for misunderstanding you.
 80 2011-12-02 02:22:32 <etotheipi_> no worries, I wasn't clear
 81 2011-12-02 02:23:02 <etotheipi_> I was just reading a post about the max op-codes per block, and I assumed everyone else was on the same wavelength
 82 2011-12-02 02:23:03 <theymos> gmaxwell: Is the current plan to do this stuff using OP_EVAL?
 83 2011-12-02 02:23:48 <gmaxwell> Yes. Well, thats gavin's grand plan. I'm not sure what the status of the support is for that in the broader community.
 84 2011-12-02 02:23:51 <gmaxwell> I like it.
 85 2011-12-02 02:23:58 <theymos> I also like it.
 86 2011-12-02 02:24:50 <gmaxwell> I also like that it moves the bulk of many kinds of complicated scripts to the input which can always be pruned right away.
 87 2011-12-02 02:25:03 <etotheipi_> I'm working on a client that will handle/detect/construct the M-of-N-using-OPCHECKMULTISIG transactions... OP_EVAL is a lot harder to support
 88 2011-12-02 02:25:35 <gmaxwell> etotheipi_: once you can validate it, I don't see why its any harder.  and if you can't validate it, you won't be able to be a full node on a network that uses it.
 89 2011-12-02 02:25:37 <theymos> The opcode counting method could be changed for OP_EVAL input if that's a problem. Count everything but signatures as 0.01 or something.
 90 2011-12-02 02:25:46 <gmaxwell> theymos: that was part of the plan I thought.
 91 2011-12-02 02:25:57 <theymos> Oh, I hadn't heard about that.
 92 2011-12-02 02:26:01 <gmaxwell> well, not that specific change but changing the counting.
 93 2011-12-02 02:26:22 <etotheipi_> gmaxwell, it's because I have to implement the new op-code and [controlled] recusion in the scripting engine...
 94 2011-12-02 02:26:35 <etotheipi_> I guess it's not THAT bad, but it's not trivial
 95 2011-12-02 02:26:49 <luke-jr> theymos: would you also object to a modified backport of the orphan-flood fix which has the client-ban code removed?
 96 2011-12-02 02:27:05 <gmaxwell> etotheipi_: not really terrible on the scale of everything else you need to get right.
 97 2011-12-02 02:27:26 <etotheipi_> gmaxwell, except that everything else I need to get right is already implemented... OP_EVAL is not
 98 2011-12-02 02:27:34 <theymos> luke-jr: Backporting should be avoided unless it's likely to be a serious problem.
 99 2011-12-02 02:27:54 <luke-jr> theymos: without the fix, it leaves the client open to attack
100 2011-12-02 02:28:04 <etotheipi_> I finished my scripting engine months ago... and I don't have to touch it to support OP_CHECKMULTISIG
101 2011-12-02 02:28:12 <gmaxwell> etotheipi_: yes. But thats true of any change or improvement, I hope you recognize that that line of thinking has somewhat poisonous conclusions.
102 2011-12-02 02:28:29 <theymos> luke-jr: Then it should be backported.
103 2011-12-02 02:29:19 <etotheipi_> gmaxwell, I know what you are saying... my issue is that I want to provide support for OP_CMS in my client, and it seems easier to me than OP_EVAL which I plan to do later
104 2011-12-02 02:29:19 <gmaxwell> etotheipi_: e.g. that there can't be any improvements _at all_ no mater how significant, because other people will need to do some work.
105 2011-12-02 02:30:27 <gmaxwell> etotheipi_: It sounds fairly likely that the OP_EVAL will eventually become the norm. You can get ahead of that or you can do something a bit easier now, but have to do it over against later.
106 2011-12-02 02:30:44 <etotheipi_> gmaxwell, I'm not convinced of that at all
107 2011-12-02 02:31:01 <etotheipi_> but I haven't been on the bleeding edge of this thought-train, though
108 2011-12-02 02:31:22 <etotheipi_> I was under the impression that OP_CHECKMULTISIG was somewhat complimentary to OP_EVAL
109 2011-12-02 02:31:37 <gmaxwell> I think the storage argument alone will strongly discourage the use of any transaction output scripts which are not either classic standard transactions or OP_EVAL.
110 2011-12-02 02:32:07 <etotheipi_> obviously, there is redundancy in what they can do, but OP_EVAL does not allow one to detect their own transactions easily
111 2011-12-02 02:32:16 <gmaxwell> (because it closes a lot of 'stuffing random data in the blockchain' issues)
112 2011-12-02 02:32:20 <gmaxwell> etotheipi_: sure it does.
113 2011-12-02 02:32:24 <etotheipi_> if what you were saying was true, I would expect Gavin to forego BIP 0011
114 2011-12-02 02:32:31 <gmaxwell> etotheipi_: you can detect your transactions because you provided the address.
115 2011-12-02 02:32:50 <etotheipi_> (yeah, that's a bad argument)
116 2011-12-02 02:33:01 <gmaxwell> Whats a bad argument?
117 2011-12-02 02:33:08 <etotheipi_> err.. my argument about Gavin
118 2011-12-02 02:33:29 <gmaxwell> oh.
119 2011-12-02 02:34:20 <theymos> I'm a little surprised that OP_EVAL wasn't in the original design. It really simplifies things.
120 2011-12-02 02:34:52 <gmaxwell> etotheipi_: I'd strongly caution against implenting any client that 'detects' transactions as IsMine that it didn't prototype that it can't currently satisify.
121 2011-12-02 02:35:07 <gmaxwell> theymos: it's comforting that not _everything_ was thought of.
122 2011-12-02 02:35:36 <gmaxwell> theymos: but yes, it would have been better of OP_EVAL was the only kind then you could have made the output scripts have very tight size limits.
123 2011-12-02 02:36:07 <etotheipi_> gmaxwell, I'm not entirely convinced ... but I'll think about it
124 2011-12-02 02:37:04 <gmaxwell> etotheipi_: It seems that a lot of people think that there is some bijection between private keys and addresses... and thats not really the case even now. (e.g. the same private key could have a different address if used in point compressed form)
125 2011-12-02 02:37:27 <etotheipi_> in fact... if deterministic wallets are ever going to be the norm... then OP_EVAL *guarantees* that you must have CONSTANT backup of your wallet... or you lose access to all the OP_EVAL txs that you created since you last backed up
126 2011-12-02 02:37:27 <gmaxwell> Really you should think of addresses as short forms for a output script that the reciever is sure to understand.
127 2011-12-02 02:37:38 <gmaxwell> etotheipi_: that isn't true at all.
128 2011-12-02 02:38:04 <gmaxwell> etotheipi_: you can determinsitically generate your OP_EVAL addresses the same way as you determinstically generate anythign else.
129 2011-12-02 02:38:37 <etotheipi_> I know what address *I* used, but how do I know all the other addresses that were part of the script?
130 2011-12-02 02:39:10 <gmaxwell> You have to provide them. But if you don't have them you already can't identify the transaction as something you could potentially ever spend.
131 2011-12-02 02:39:16 <etotheipi_> I have no way to tell that I have a piece of a multi-sig OP_EVAL script unless I specifically save the subscript that was used to create it
132 2011-12-02 02:40:14 <gmaxwell> You still don't otherwise, unless you want your client to be trivially vulnerable to flooding attackes where I generate B or (impossible and etotheipi_)
133 2011-12-02 02:40:45 <etotheipi_> with OP_CHECKMULTI sig, you don't have to play games, you know you can identify transactions that involve you -- maybe you don't think that's a significant benefit ... but for a client developer like me it matters
134 2011-12-02 02:40:55 <gmaxwell> You're incorrect.
135 2011-12-02 02:41:34 <gmaxwell> Again, I can start making all my transactions pay to B or (0 and etotheipi_). The transactions don't involve you, but if you try to sniff for ones that do you will.
136 2011-12-02 02:41:39 <gmaxwell> er will think they do.
137 2011-12-02 02:42:19 <gmaxwell> And even if you find one that involves you you have no clue how to spend it.
138 2011-12-02 02:42:54 <gmaxwell> It might involve you but you don't know who the other parties are. Unless you've configured them and if you've configured them, then you can generate the OP_EVAL addresses determinstically.
139 2011-12-02 02:44:23 <etotheipi_> okay, I'm going to have to sleep on this one, because I'm going to have to ponder what you're saying
140 2011-12-02 02:44:27 <gmaxwell> Okay!
141 2011-12-02 02:44:50 <etotheipi_> but I recognize there are valuable points in there... but I can't grok it at the moment
142 2011-12-02 02:45:38 <gmaxwell> I'll be glad to discuss it later too. I've spent a while pondering this, and I think I'm pretty confident at this point that it's a sane position.
143 2011-12-02 02:45:47 <gmaxwell> but who knows. :)
144 2011-12-02 02:45:52 <etotheipi_> what is Gavin's take on it?
145 2011-12-02 02:46:15 <etotheipi_> have you had this discussion with him?  I only ask because he's the one supporting upgrading to OP_CMS
146 2011-12-02 02:47:00 <gmaxwell> There was a thread on the list where someone basically made (in a much louder form) the argument that you won't know which txn are yours. And I think it was finally accepted that this wasn't sure.
147 2011-12-02 02:47:10 <gmaxwell> The reason for supporting OP_CMS is that its a good fast solution.
148 2011-12-02 02:47:18 <gmaxwell> Right now OP_EVAL will require massive miner upgrades.
149 2011-12-02 02:47:25 <etotheipi_> btw, gmaxwell -- I never said I was assuming I could spend txs that involve me... I'm just collecting them -- I know better than to assume I can spend them
150 2011-12-02 02:47:42 <gmaxwell> Whereas OP_CMS can be done pretty much right away.
151 2011-12-02 02:47:50 <etotheipi_> fair enough
152 2011-12-02 02:48:15 <gmaxwell> etotheipi_: but it's quite tricky there. If you display them to the user you will create vulnerabilties... where I send the users txns that they have no hope of ever spending.
153 2011-12-02 02:49:06 <gmaxwell> Maybe you've figured out some UI solutions that would make that okay, I don't know.
154 2011-12-02 02:49:35 <etotheipi_> at the moment, I'm getting my code base to recognize them and collect them in memory:  I'm not sure exactly what I"m going to do with them, yet, though
155 2011-12-02 02:49:56 <etotheipi_> I definitely see your point about spamming my client with transactions I can't spend
156 2011-12-02 02:50:56 <etotheipi_> I envisioned (your point) that you would only be dealing with multi-sig transactions that you either created yourself, or someone else created that you were expecting to see
157 2011-12-02 02:51:14 <gmaxwell> Once you have some data about txn you know how to get signatures for... then you can easily generate the scripts determinstically. e.g. if you do some kind of create_special_account->add_second_signer->url=to_request_signing;pubkey=foo .. then you can then find the matching txn.
158 2011-12-02 02:53:19 <etotheipi_> okay, I'll think about this... for now I'm going to plow forward with my multi-sig support since no client is doing this yet
159 2011-12-02 02:53:57 <etotheipi_> I'd love to continue this when I'm not so busy trying to get out a first release
160 2011-12-02 02:54:19 <gmaxwell> etotheipi_: there are patches to bitcoin to do OP_CMS... of course.
161 2011-12-02 02:54:44 <etotheipi_> yeah, but how do you actually create them and collect signatures?
162 2011-12-02 02:54:57 <etotheipi_> that's the real meat of what I'm doing
163 2011-12-02 02:55:30 <etotheipi_> is efficiently transmitting, signing, and collecting signatures without needing a master's degree in BTC to know what the hell is going on
164 2011-12-02 02:56:08 <etotheipi_> I'm sure there will be an easy upgrade to OP_EVAL when that becomes more relevant
165 2011-12-02 02:56:11 <gmaxwell> hm? the stuff in groffer's patch was easy enough to use (ignoring the lack of a GUI)
166 2011-12-02 02:56:44 <etotheipi_> okay, I'm not familiar with it... but there's a $250 bounty out there for good OP_CMS support right now... it sounds like any current solutions are not sufficient ones
167 2011-12-02 02:56:55 <etotheipi_> maybe it's just because the protocol won't take it yet
168 2011-12-02 02:57:04 <etotheipi_> *err... network won't take it yet
169 2011-12-02 02:57:21 <gmaxwell> Where is this bounty?
170 2011-12-02 02:57:40 <etotheipi_> https://bitcointalk.org/index.php?topic=48215.0
171 2011-12-02 02:58:16 <theymos> For Bitcoin Block Explorer I was planning on initially displaying 2xxxx addresses and then simplifying to a cannoical 1xxxx or (1xxxx AND 1xxxx) form where/when possible. You think this is correct?
172 2011-12-02 02:59:03 <gmaxwell> etotheipi_: someone is just being .. a bit silly about that bounty.
173 2011-12-02 02:59:15 <gmaxwell> Gavin has an implementation, and there is the older one: https://github.com/groffer/bitcoin/blob/escrow/doc/README_escrow.txt
174 2011-12-02 03:01:10 <gmaxwell> Diablo-D3: Care to explain why you locked my thread on the forum?
175 2011-12-02 03:01:30 <theymos> What thread?
176 2011-12-02 03:01:42 <gmaxwell> theymos: the is butterfly labs a scam thread.
177 2011-12-02 03:02:06 <gmaxwell> There is plenty of perfectly reasonable and intresting discussion there. Just because a couple people are being argumentative isn't a reason to lock the thread. :-/
178 2011-12-02 03:02:19 <gmaxwell> (it's a reason to tell them to chill out)
179 2011-12-02 03:02:46 <theymos> It is a pretty large thread. Maybe better to start a new one.
180 2011-12-02 03:03:45 <gmaxwell> K.
181 2011-12-02 03:22:12 <gmaxwell> Diablo-D3: a link in the old thread to the new one would be nice.
182 2011-12-02 03:23:44 <Diablo-D3> gmaxwell: I got tired of the flaming and bullshit.
183 2011-12-02 03:24:30 <Diablo-D3> dont want me to lock threads? hope and pray my inbox isnt flooded with reported message emails.
184 2011-12-02 03:24:37 <gmaxwell> then cluestick the flamers. I agree the flaming is dumb, but the thread has been interesting overall.
185 2011-12-02 03:24:58 <Diablo-D3> why cluebar the flamers when I can cluenuke the thread.
186 2011-12-02 03:25:02 <Diablo-D3> seems to be more efficient.
187 2011-12-02 03:25:23 <gmaxwell> Because there is plenty of perfectly sane discussion going on there.
188 2011-12-02 03:25:46 <Diablo-D3> seriously, a motherfucking mushroom cloud of clue
189 2011-12-02 03:25:49 <Diablo-D3> shaped like a giant penis.
190 2011-12-02 03:25:52 <gmaxwell> And because if you keep that pattern up anyone can kill any thread by dropping a couple argumentative socks in it.
191 2011-12-02 03:26:00 <Diablo-D3> gmaxwell: honestly
192 2011-12-02 03:26:05 <Diablo-D3> if people are stupid enough to take the bait
193 2011-12-02 03:26:13 <Diablo-D3> the thread deserves being locked
194 2011-12-02 03:26:42 <theymos> It would be better to remove the garbage from the thread, though it's pretty hard when the thread's 70 pages long.
195 2011-12-02 03:27:01 <Diablo-D3> yeah, at 70 pages, its a tad late.
196 2011-12-02 03:27:12 <Diablo-D3> theres maybe 5 pages of salvagable content
197 2011-12-02 03:27:17 <gmaxwell> Thats nonsense.
198 2011-12-02 03:27:37 <Diablo-D3> 65 pages of nonsense, yes.
199 2011-12-02 03:27:37 <gmaxwell> Most of the pages aren't hostile at all. Just regular discussion.
200 2011-12-02 03:28:20 <Diablo-D3> if butterfly labs runs off with all the money, then hire a goddamned lawyer
201 2011-12-02 03:28:26 <Diablo-D3> no amount of forum threads are going to fix it
202 2011-12-02 03:28:30 <gmaxwell> There are many pages of just boing discussion, e.g. like the pictures from Inaba's meeting with them.
203 2011-12-02 03:29:22 <Diablo-D3> theymos: just make gmaxwell a mod already so he shuts up.
204 2011-12-02 03:29:30 <gmaxwell> Diablo-D3: hah
205 2011-12-02 03:29:31 <Diablo-D3> if he wants it cleaned up so badly, he can do it
206 2011-12-02 03:29:35 <theymos> You want to be a mod, gmaxwell?
207 2011-12-02 03:29:52 <gmaxwell> Oy. Not really, but that probably qualifies me for it.
208 2011-12-02 03:29:55 <gmaxwell> :)
209 2011-12-02 03:30:00 <Diablo-D3> derp.
210 2011-12-02 03:30:29 <Diablo-D3> btw, this wouldnt be nearly the problem it was if I could retroactively nuke accounts
211 2011-12-02 03:30:32 <gmaxwell> Diablo-D3: yea, well, if you look at the thread I did try to wade in a bit and discourage the flaming a couple times. Sadly it wasn't that effective.
212 2011-12-02 03:30:33 <c_k> I showed my gf a pic of the device, pointed one of my miners and said "someone says you can get all that in to this little thing for $700 USD", she says "but the pic doesn't show perspective of size" so I show her a pic of the PCB, she says "it sounds like it's all lies"
213 2011-12-02 03:30:38 <c_k> ^ reality
214 2011-12-02 03:30:45 <Diablo-D3> not only the account, but any post they made, and even replies quoting them
215 2011-12-02 03:30:50 <Diablo-D3> gmaxwell: it never works
216 2011-12-02 03:30:53 <c_k> thats not what I said.  I said it's all shit.
217 2011-12-02 03:30:59 <c_k> ok, ^ her correcting me
218 2011-12-02 03:31:21 <gmaxwell> Diablo-D3: sure it does, sometimes. Depends on the people arguing being fundimentally reasonable though.
219 2011-12-02 03:31:23 <c_k> someone met with butterfly labs?
220 2011-12-02 03:31:38 <Diablo-D3> gmaxwell: fundementally reasonable people? can I have some of those drugs? they sound fun
221 2011-12-02 03:31:43 <theymos> gmaxwell: You're a mining mod now.
222 2011-12-02 03:32:00 <gmaxwell> c_k: yes. Inaba, operator of the eclipse pool lives about 30 miles from them apparently.
223 2011-12-02 03:32:22 <c_k> gmaxwell: cool, did he get to see one in action?
224 2011-12-02 03:32:43 <Diablo-D3> gmaxwell: lock thread, unlock thread, delete posts in said thread, I dont care, just have fun
225 2011-12-02 03:34:46 <gmaxwell> c_k: Kinda. He's actually going to be doing some benchmarking but it's been delayed because of problems with their mining software.
226 2011-12-02 03:35:00 <gmaxwell> c_k: he played with one, put it on a power meter, but didn't actually have it mining on his pool.
227 2011-12-02 03:38:34 <theymos> gmaxwell: When you clean that thread, you can turn on "quick moderation" in your personal forum settings to easily delete many posts at once.
228 2011-12-02 03:39:53 <Diablo-D3> I love that feature
229 2011-12-02 03:40:42 <cocktopus> i bet you do
230 2011-12-02 03:49:11 <SomeoneWeird> lol
231 2011-12-02 04:12:57 <Diablo-D3> ;;ticker
232 2011-12-02 04:12:58 <gribble> Best bid: 3.1, Best ask: 3.1011, Bid-ask spread: 0.0011, Last trade: 3.1, 24 hour volume: 69251, 24 hour low: 2.99002, 24 hour high: 3.14
233 2011-12-02 06:42:53 <pickett> priv key in hex format is always 64 characters?
234 2011-12-02 06:55:54 <phantomcircuit> pickett, could be 32 w/o half of the curve
235 2011-12-02 06:56:59 <gmaxwell> phantomcircuit: private key.
236 2011-12-02 06:57:23 <phantomcircuit> oh
237 2011-12-02 06:57:24 <phantomcircuit> right
238 2011-12-02 06:58:06 <gmaxwell> pickett: a private key is always 256 bits. How that gets represented is ?? to me something could base64 encode smaller values and pack the rest with zeros, for example, and end up with less digits.
239 2011-12-02 06:58:18 <gmaxwell> I don't know how any particular representation works.
240 2011-12-02 06:59:38 <pickett> anyone know how to sha256sum a single word in ubuntu?
241 2011-12-02 06:59:44 <pickett> i cna only get it to do files
242 2011-12-02 07:00:31 <phantomcircuit> echo "single word"|sha256sum
243 2011-12-02 07:01:55 <upb> echo -n
244 2011-12-02 07:02:39 <pickett> thanks the -n makes it right
245 2011-12-02 13:44:18 <snimpy> ;;bc,diffchange
246 2011-12-02 13:44:19 <gribble> Estimated percent change in difficulty this period | 15.8506564552 % based on data since last change | 18.7570089393 % based on data for last three days
247 2011-12-02 13:44:37 <snimpy> ;;bc,convert
248 2011-12-02 13:44:38 <gribble> Error: invalid syntax (<string>, line 1)
249 2011-12-02 13:44:47 <snimpy> ;;bc,convert
250 2011-12-02 13:44:48 <gribble> Error: invalid syntax (<string>, line 1)
251 2011-12-02 13:45:00 <gribble> Error: invalid syntax (<string>, line 1)
252 2011-12-02 13:45:00 <snimpy> ;;bc,convert eur
253 2011-12-02 13:45:13 <gribble> Best bid: 3.12464, Best ask: 3.13, Bid-ask spread: 0.00536, Last trade: 3.12464, 24 hour volume: 62452, 24 hour low: 2.9901, 24 hour high: 3.14
254 2011-12-02 13:45:13 <snimpy> ;;ticker
255 2011-12-02 13:51:25 <gribble> Error: "temp" is not a valid command.
256 2011-12-02 13:51:25 <snimpy> ;;temp
257 2011-12-02 13:52:21 <snimpy> ;;bc,diffchange
258 2011-12-02 13:52:22 <gribble> Estimated percent change in difficulty this period | 15.8506564552 % based on data since last change | 18.7570089393 % based on data for last three days
259 2011-12-02 13:53:04 <snimpy> ;;bc,stats
260 2011-12-02 13:53:07 <gribble> Current Blocks: 155734 | Current Difficulty: 1090715.6800513 | Next Difficulty At Block: 157247 | Next Difficulty In: 1513 blocks | Next Difficulty In About: 1 week, 2 days, 2 hours, 7 minutes, and 27 seconds | Next Difficulty Estimate: 1263601.27539856 | Estimated Percent Change: 15.8506564552
261 2011-12-02 13:53:20 <snimpy> ;;bc,stats
262 2011-12-02 13:53:22 <gribble> Current Blocks: 155734 | Current Difficulty: 1090715.6800513 | Next Difficulty At Block: 157247 | Next Difficulty In: 1513 blocks | Next Difficulty In About: 1 week, 2 days, 2 hours, 7 minutes, and 27 seconds | Next Difficulty Estimate: 1263601.27539856 | Estimated Percent Change: 15.8506564552
263 2011-12-02 13:54:01 <snimpy> ;;bc,xau
264 2011-12-02 13:54:02 <gribble> 1 XAU = 1748.790000000000 USD = 562.311897106 BTC
265 2011-12-02 13:55:14 <snimpy> hello
266 2011-12-02 14:09:44 <CIA-100> bitcoin: Gavin Andresen master * r43ae68b / (src/init.cpp src/net.cpp src/net.h): Merge pull request #654 from TheBlueMatt/dnsseed-thread ... https://github.com/bitcoin/bitcoin/commit/43ae68b5efb2d7f8c23f64d3efdbd49c9d90aff2
267 2011-12-02 14:46:32 <gavinandresen> [Tycho]: do you need anything from me to get multisignature/OP_EVAL implemented?
268 2011-12-02 14:55:39 <[Tycho]> Hello, gavinandresen. I received your patch.
269 2011-12-02 14:55:58 <[Tycho]> Not tried to apply it yet.
270 2011-12-02 14:56:47 <[Tycho]> So it will accept blocks with OP_EVAL, but will not accept transactions with OP_EVAL as valid ?
271 2011-12-02 14:57:58 <gavinandresen> [Tycho]: a little more complicated than that...
272 2011-12-02 14:58:51 <gavinandresen> It will mine and relay OP_EVAL transactions that are valid under both the old and new interpretation of OP_EVAL.
273 2011-12-02 14:59:05 <slush> gavinandresen: I also received the patch, will need to test it soon. It's pretty complex and incompatible with some of my patches in getwork area, but I think I can solve that
274 2011-12-02 14:59:41 <gavinandresen> If it gets an OP_EVAL transaction that is valid under the old rules but invalid under the NEW rules, then it will NOT mine or relay it.  But it will accept them if they appear in already-mined blocks.
275 2011-12-02 15:00:14 <gavinandresen> The only way for that to happen is if somebody wanted to try to intentionally split the blockchain.
276 2011-12-02 15:00:26 <gavinandresen> ... which I assume somebody WOULD try, if they can.
277 2011-12-02 15:00:41 <gavinandresen> slush:  I've got an alternate patch against 0.3.24 that might apply easier
278 2011-12-02 15:01:31 <slush> gavinandresen: if it is simpler (and it works), I'll appreciate it
279 2011-12-02 15:02:19 <gavinandresen> slush:  I'll split out out from the 'vinced merged mining' branch I did for another pool
280 2011-12-02 15:02:41 <slush> great!
281 2011-12-02 15:02:56 <slush> it will help me a lot
282 2011-12-02 15:04:28 <gavinandresen> slush: https://github.com/gavinandresen/bitcoin-git/tree/v0.3.24_op_eval
283 2011-12-02 15:07:06 <slush> gavinandresen: those two commits: "OP_EVAL and m-of-3 standard multisignature support", "Merge commit 'v0.3.24' into v0.3.23_op_eval" ?
284 2011-12-02 15:09:24 <gavinandresen> slush:  one sec, let me look....
285 2011-12-02 15:09:47 <gavinandresen> slush:  ... and let me rebase onto 0.3.24, that should be cleaner
286 2011-12-02 15:14:52 <gavinandresen> slush:  hang on, that branch wasn't doing the right thing
287 2011-12-02 15:15:45 <slush> gavinandresen: ok, I'll wait. I still cannot try it soon than next week, so don't hurry
288 2011-12-02 15:26:18 <gavinandresen> slush: rebased into a single commit against v0.3.24 :  https://github.com/gavinandresen/bitcoin-git/commit/efe91f8cde42d84540626fc7abaeb89fecaff93f
289 2011-12-02 15:28:38 <slush> great, looks pretty good. Is that extension in coinbase so important? I'm not sure if it don't break merged mining
290 2011-12-02 15:29:26 <gmaxwell> It should be compatible with merged mining, but I don't know if anyone has tested it yet.
291 2011-12-02 15:29:59 <gmaxwell> If its not, then namecoin ought to be fixed.
292 2011-12-02 15:30:10 <gmaxwell> The ability to communicate support with coinbase flags is quite useful.
293 2011-12-02 15:30:24 <sipa> afaik it just uses a substring test?
294 2011-12-02 15:30:44 <gmaxwell> As for importance it's kinda important, you don't want to start accepting the new txn unless a majority (really a super majority) of the mining power is enforcing them, lest you get orphaned.
295 2011-12-02 15:31:33 <gavinandresen> Actually, it is perfectly safe to accept/mine/relay OP_EVAL transactions, as long as they're valid under both new and old rules.
296 2011-12-02 15:31:36 <gmaxwell> Because there are few enough big pools perhaps we can get that confidence today without it.. but the mechenism should still work in case things are more distributed next year.
297 2011-12-02 15:31:58 <gmaxwell> oh. hmph.
298 2011-12-02 15:32:00 <gmaxwell> duh.
299 2011-12-02 15:32:03 <gavinandresen> The dangerous thing is to outright reject blocks that contain OP_EVAL transactions that are valid under old rules, invalid under new.
300 2011-12-02 15:32:16 <gmaxwell> oh right. That.
301 2011-12-02 15:33:50 <gmaxwell> In any case, though I was being stupid on the cause the net is that if you start fully applying the new behavior without a majority thats bad for your mining success.
302 2011-12-02 15:53:13 <ByteCoin> Gavin: I believe I have found a good implementation of (a and b) or c transactions which can be redeemed even if a and b are forgotten. Have a look sometime https://bitcointalk.org/index.php?topic=48215.msg638042#msg638042
303 2011-12-02 16:15:59 <luke-jr> gavinandresen: I presume the new rules include "if it was invalid under the old rules, it isn't valid here either"?
304 2011-12-02 16:16:50 <sipa> luke-jr: yes
305 2011-12-02 16:16:59 <gavinandresen> luke-jr: yes, there is an explicit check, OP_EVAL transactions must evaluate to true if the EVAL is interepreted as a no-op
306 2011-12-02 16:17:37 <luke-jr> gavinandresen: in case you forgot, I was still hoping for a 0.3.23 patch that applies with 'git am' (ie, has git headers)
307 2011-12-02 16:17:52 <gavinandresen> luke-jr: I thought I sent you one....
308 2011-12-02 16:18:05 <luke-jr> hmm
309 2011-12-02 16:18:14 <luke-jr> let me check spam/caught
310 2011-12-02 16:18:49 <luke-jr> does the code automatically do the switch yet?
311 2011-12-02 16:19:15 <gavinandresen> you mean "look for a majority "OP_EVAL" in coinbases?"  no
312 2011-12-02 16:19:28 <luke-jr> nothing in spam/caught& double-checking inbox
313 2011-12-02 16:19:33 <gavinandresen> I'll resend
314 2011-12-02 16:20:27 <luke-jr> gavinandresen: you made it with `git format-patch', right?
315 2011-12-02 16:20:36 <luke-jr> (a link to a git repo would be fine, too)
316 2011-12-02 16:21:41 <jrmithdobbs> where'd the display for current block go in bitcoin-qt?
317 2011-12-02 16:21:50 <gavinandresen> luke-jr:  https://github.com/gavinandresen/bitcoin-git/tree/v0.3.23_op_eval
318 2011-12-02 16:21:55 <sipa> jrmithdobbs: tooltip
319 2011-12-02 16:22:07 <jrmithdobbs> annoying over latent vnc :(
320 2011-12-02 16:22:11 <jrmithdobbs> where's the tooltip at?
321 2011-12-02 16:22:16 <gavinandresen> There is also https://github.com/gavinandresen/bitcoin-git/tree/v0.3.24_op_eval
322 2011-12-02 16:22:29 <gavinandresen> and https://github.com/gavinandresen/bitcoin-git/tree/v0.4.1_op_eval
323 2011-12-02 16:23:16 <cocktopus> jrmithdobbs: bottom right hand corner where the green tick is
324 2011-12-02 16:27:34 <luke-jr> gavinandresen: wtf? :P https://github.com/gavinandresen/bitcoin-git/commit/94677dc539b4603624afc6d82812aa22126083cb#L3L1092
325 2011-12-02 16:28:46 <gavinandresen> luke-jr: must be gremlins.
326 2011-12-02 16:29:09 <gmaxwell> it's the new 'wave' /0/ style indenting.
327 2011-12-02 16:38:38 <helo> when are miners encouraged to include OP_EVAL in their blocks?
328 2011-12-02 16:39:55 <Eliel> so, how many here tried the osiris p2p forum system yet? Some people appear to have put up a bitcoin forum there too. The system appears to work pretty well.
329 2011-12-02 16:40:25 <Eliel> https://bitcointalk.org/index.php?topic=46206.0
330 2011-12-02 16:40:45 <luke-jr> gavinandresen: for "maximum automatic fee", does a default of 1 BTC sound reasonable?
331 2011-12-02 16:40:51 <luke-jr> or maybe CENT would be better
332 2011-12-02 16:42:23 <gavinandresen> helo: I'm encouraging miners to support OP_EVAL now.
333 2011-12-02 16:42:59 <helo> good
334 2011-12-02 16:43:22 <gavinandresen> luke-jr: ... you mean "have the RPC calls fail if fee would be more than..." ?  CENT seems like a reasonable default, with switch to override
335 2011-12-02 16:43:22 <sipa> Unless you're solo mining, you won't know, however
336 2011-12-02 16:43:25 <helo> it will be pretty interesting to see fast it starts appearing
337 2011-12-02 16:43:42 <helo> among solo miners, at least
338 2011-12-02 16:44:41 <luke-jr> gavinandresen: he means but it in blocks
339 2011-12-02 16:45:48 <gavinandresen> Right, I'm encouraging miners to start relaying and mining valid-under-both-old-and-new-rules transactions now.  And to express that support by putting "OP_EVAL" in coinbases....
340 2011-12-02 16:45:58 <luke-jr> oh
341 2011-12-02 16:46:11 <luke-jr> I thought it only worked after a certain block time
342 2011-12-02 16:46:33 <ByteCoin> gavinandresen: Are you interested in a (a and b) or c solution in the short term?
343 2011-12-02 16:46:41 <gavinandresen> The after-a-certain-block-time controls when you outright REJECT blocks that contain bogus OP_EVAL transactions.
344 2011-12-02 16:47:06 <gavinandresen> ByteCoin: I'm interested.... need to think about your proposal a bit more...
345 2011-12-02 16:47:39 <ByteCoin> gavinandresen: Ok. Just checking you'd seen it.
346 2011-12-02 16:49:30 <ByteCoin> From the point of view of implementing OP_EVAL 2 of 2 multisignature transactions, I'm presuming that the serialized script that hashes to the address is stored in the wallet in some fashion. Correct?
347 2011-12-02 16:49:34 <luke-jr> gavinandresen: so you're encouraging people to use it, even now when the funds can be stolen easy?
348 2011-12-02 16:51:38 <gavinandresen> luke-jr: no, the RPC call that enables it (addmultisigaddress) is disabled unless you're on -testnet
349 2011-12-02 16:52:06 <gavinandresen> ... so it is "Use it at your own risk until a majority of miners support"
350 2011-12-02 16:54:15 <gavinandresen> OP_EVAL transactions are actually pretty safe, even if the OP_EVAL is interepreted as a no-op
351 2011-12-02 16:55:28 <gavinandresen> ... if you're a little careful not to re-use your keys.
352 2011-12-02 16:57:49 <gavinandresen> I shouldn't say "pretty safe" -- I should say "safer than you might think".  Stealing them isn't trivial.
353 2011-12-02 16:58:23 <luke-jr> oh, the address hashes are checked even with NOP?
354 2011-12-02 16:58:44 <gavinandresen> the hash of the redemption script, yes.
355 2011-12-02 16:59:04 <gavinandresen> (and the pubkeys are part of that hash)
356 2011-12-02 17:04:24 <[Tycho]> Hello, gavinandresen.
357 2011-12-02 17:04:39 <gavinandresen> howdy [Tycho]
358 2011-12-02 17:05:02 <[Tycho]> I received your patch recently.
359 2011-12-02 17:05:11 <[Tycho]> So it will accept blocks with OP_EVAL, but will not accept transactions with OP_EVAL as valid ?
360 2011-12-02 17:06:36 <gavinandresen> [Tycho]: if it gets an OP_EVAL transaction that is completely 100% valid, then it will accept it, relay it, mine it, etc.
361 2011-12-02 17:07:16 <[Tycho]> Will this block be accepted by other miners ?
362 2011-12-02 17:07:21 <gavinandresen> [Tycho]: yes
363 2011-12-02 17:07:35 <[Tycho]> Why ?
364 2011-12-02 17:07:39 <gavinandresen> [Tycho]: OP_EVAL is the same as OP_NOP1
365 2011-12-02 17:07:45 <[Tycho]> Cool.
366 2011-12-02 17:08:26 <[Tycho]> So preferred deploying time is until 15.01 ?
367 2011-12-02 17:09:00 <gavinandresen> Preferred deploying time is now.
368 2011-12-02 17:09:21 <[Tycho]> I remember 15.01 mentioned somewhere...
369 2011-12-02 17:09:49 <gavinandresen> That is when I'll run some code to see what percentage of blocks are supporting it
370 2011-12-02 17:11:29 <gavinandresen> ... and if most are, then on Feb 1 the rules for one edge case switch, and any miners NOT running the new code AND accepting non-standard transactions would be in danger of not having their blocks accepted.
371 2011-12-02 17:12:15 <gavinandresen> That will also be the signal that it is safe to tell users to start using OP_EVAL transactions.
372 2011-12-02 17:18:16 <luke-jr> gavinandresen: could you double-check my merge for Eligius? I had quite a few conflicts :/
373 2011-12-02 17:18:39 <gavinandresen> luke-jr: sure, happy to
374 2011-12-02 17:18:43 <luke-jr> delta: http://paste.pocoo.org/show/515846/ ; merge: http://paste.pocoo.org/show/515847/
375 2011-12-02 17:20:44 <gavinandresen> luke-jr: I assumed you'd rip out the put-"OP_EVAL" in the coinbase code I wrote and replace it with your own...
376 2011-12-02 17:21:03 <luke-jr> http://paste.pocoo.org/show/515846/ is probably the clearer one to read
377 2011-12-02 17:21:13 <luke-jr> gavinandresen: yeah, mine is a simple few-liner in init.cpp ;)
378 2011-12-02 17:21:58 <luke-jr> oooh I missed a spot
379 2011-12-02 17:22:39 <luke-jr> & or did I?
380 2011-12-02 17:22:59 <luke-jr> ok, this is the 'git diff' http://paste.pocoo.org/show/515853/
381 2011-12-02 17:23:32 <gavinandresen> in the merge Solver()  code:  what's the  ... while (opcode == OP_NOP) loops for?
382 2011-12-02 17:23:50 <luke-jr> gavinandresen: ignoring OP_NOPs entirely, when trying to solve it :P
383 2011-12-02 17:23:56 <luke-jr> that's not part of this merge
384 2011-12-02 17:24:00 <gavinandresen> ah, ok
385 2011-12-02 17:24:58 <[Tycho]> Oh, git gui for macos doesn't accepts .patch files automatically...
386 2011-12-02 17:25:21 <luke-jr> gavinandresen: hmm, is there a chance that will break, with this new stuff?
387 2011-12-02 17:25:48 <gavinandresen> luke-jr: shouldn't, OP_NOP is different from OP_NOP1
388 2011-12-02 17:29:27 <gavinandresen> luke-jr: code changes look good to me, but if I were you I'd mine a few blocks on a testnet-in-a-box to make sure it was all working properly.
389 2011-12-02 17:29:43 <luke-jr> good idea
390 2011-12-02 17:30:26 <gavinandresen> My 0.3.23-based code had a bug that I didn't find until I tried getwork-mining on testnet-in-a-box...
391 2011-12-02 17:39:51 <gavinandresen> Anybody have opinions on whether a bug-fix-only 0.5.1 release is worth doing?
392 2011-12-02 17:40:01 <[Tycho]> "gavinandresen: My 0.3.23-based code had a bug" - the one in your patch or earlier ?
393 2011-12-02 17:40:32 <gavinandresen> [Tycho]: earlier.  I DO try hard to test things thoroughly....
394 2011-12-02 17:41:37 <gavinandresen> Arguments for a 0.5.1 :   Fix the black-rollover-tooltips problem.  Get the DoS-prevention fix out sooner. And a bunch of translations were updated....
395 2011-12-02 17:43:28 <[Tycho]> Looks like I'll have to do this via command line.
396 2011-12-02 17:44:37 <[Tycho]> gavinandresen: is there any plan on fixing 4-byte limit or it will left broken forever ?
397 2011-12-02 17:44:49 <luke-jr> gavinandresen: That OP_EVAL change will go live tomorrow when I restart bitcoind
398 2011-12-02 17:45:14 <luke-jr> gavinandresen: your master branch already has non-fixes, so the stable repo has a 0.5.x branch for 0.5.1
399 2011-12-02 17:46:36 <gavinandresen> luke-jr: I don't see any changes that would justify a 0.5->0.6 version bump
400 2011-12-02 17:47:08 <gavinandresen> [Tycho]: I'd like to fix that whenever we decide there is an important-enough change to justify a hard block-chain-split.
401 2011-12-02 17:47:38 <[Tycho]> It will be a hard split ? Looks like no one uses those features yet.
402 2011-12-02 17:47:46 <gavinandresen> [Tycho]: ... but the only change I can think of right now that would justify a hard block-chain split is un-hard-coding the maximum block size
403 2011-12-02 17:47:58 <imsaguy2> so with the .5 client, there's no way to see the number of connections unless a person does an rpc call, correct?
404 2011-12-02 17:48:12 <luke-jr> gavinandresen: yeah, looking at the delta, none of the bigger stuff is merged yet
405 2011-12-02 17:48:18 <gavinandresen> [Tycho]: old clients would reject blocks containing OP_ADD with operands > 4 bytes, so they'd be split off
406 2011-12-02 17:48:44 <[Tycho]> Oh, right.
407 2011-12-02 17:48:51 <gavinandresen> luke-jr: yup, I've been pulling just fixes or small-enough-not-to-be-dangerous changes
408 2011-12-02 17:48:56 <gavinandresen> (like icon color changes)
409 2011-12-02 17:49:11 <[Tycho]> But someday additional ops should be enabled anyway...
410 2011-12-02 17:49:18 <gavinandresen> [Tycho]: agreed.  someday....
411 2011-12-02 17:49:39 <luke-jr> the critical block and secure string changes, I wasn't so sure about
412 2011-12-02 17:49:51 <luke-jr> they seem more like refactors with a potential for damage
413 2011-12-02 17:50:32 <luke-jr> [Tycho]: probably the best way to handle it is to do a single block chain fork, changing as many things as possible
414 2011-12-02 17:50:33 <gavinandresen> [Tycho]: is there a particular thing you want to do with >4byte operands?
415 2011-12-02 17:51:46 <luke-jr> gavinandresen: if you decide to spin a 0.5.1 from master, I'll just rename this branch to 0.5.0.x (and probably drop support for it very soon)
416 2011-12-02 17:51:50 <[Tycho]> gavinandresen: not yet. But there is nothing to do with <= 4 byte operands anyway.
417 2011-12-02 17:52:14 <gavinandresen> luke-jr: ok.  Right now, as I said, I'm leaning towards doing a 0.5.1 from master
418 2011-12-02 17:53:03 <luke-jr> IMO, there's enough pull requests ready for merging that the ideal path is to merge them and release 0.6.0rc1 ;)
419 2011-12-02 17:53:25 <luke-jr> (and 0.5.1rc1 from the 0.5.x branch, and 0.4.2rc1 from the 0.4.x branch)
420 2011-12-02 17:53:56 <luke-jr> I'm thinking of coinbaser, QR Codes, and Bitcoin-Qt signmessage, specifically
421 2011-12-02 17:53:59 <luke-jr> I'm sure there's more though
422 2011-12-02 17:54:25 <gavinandresen> luke-jr: op_eval....
423 2011-12-02 17:54:30 <luke-jr> gavinandresen: right, OP_EVAL too
424 2011-12-02 17:55:12 <gavinandresen> Anybody else have an opinion on a 0.5.1 versus going straight to a 0.6rc1 ?
425 2011-12-02 17:55:58 <luke-jr> gavinandresen: speaking of OP_EVAL, let me know if you need/want me to rebase it against a coinbaser-merged master (it will simplify things)
426 2011-12-02 17:56:20 <gmaxwell> gavinandresen: the bigger version steps probably discourage upgrades slightly. This can be good or bad.
427 2011-12-02 17:56:59 <luke-jr> gmaxwell: any fixes are already in the 0.5.x branch
428 2011-12-02 17:57:13 <gavinandresen> luke-jr: ok-- there seems to be general consensus to pull coinbaser for 0.6, so I'll probably pull it before op_eval and rework the op_eval code to use coinbaser.
429 2011-12-02 17:57:20 <luke-jr> ie, it's not 0.5.1 /or/ 0.6rc1, it's 0.5.1 or both ;P
430 2011-12-02 17:57:42 <luke-jr> gavinandresen: I expect the change I made merging it to Eligius will be useful
431 2011-12-02 17:57:59 <luke-jr> in init.cpp, that takes care of the coinbase part entirely
432 2011-12-02 17:58:05 <gavinandresen> luke-jr: yup
433 2011-12-02 18:02:55 <[eval]> if op_eval is supported in 0.6, when will it actually be allowed on the network?
434 2011-12-02 18:03:07 <[eval]> when the miners upgrade?
435 2011-12-02 18:03:33 <gavinandresen> it is actually allowed on the network now, but nobody will relay/mine it because it is a non-standard transaction
436 2011-12-02 18:03:37 <gmaxwell> [eval]: the major miners are applying patches with backports.
437 2011-12-02 18:03:57 <gmaxwell> Talking about activitying it on feb 1st, if and only if there is a majority of hashpower with it.
438 2011-12-02 18:04:08 <gavinandresen> The steps are:  get the miners to mine it.   Then get peers to upgrade so they are relayed....
439 2011-12-02 18:04:40 <gavinandresen> ... all the while experimenting with it on the testnet...
440 2011-12-02 18:04:59 <gavinandresen> ... and finally add support for it in GUIs / web services / etc
441 2011-12-02 18:05:02 <gmaxwell> It may be some time before its really usable due to needing peers that relay it.
442 2011-12-02 18:05:38 <luke-jr> hmm
443 2011-12-02 18:05:41 <[eval]> ok :> thanks!
444 2011-12-02 18:05:53 <luke-jr> gavinandresen: I presume the 0.6 version will be live OP_EVAL?
445 2011-12-02 18:06:01 <luke-jr> ie, not the middle-stage we have now
446 2011-12-02 18:06:26 <gavinandresen> I presume that, too.
447 2011-12-02 18:08:04 <gmaxwell> gavinandresen: is it wise to use a pindexBlock->nTime instead of a height on that check?
448 2011-12-02 18:08:22 <luke-jr> gmaxwell: you can't make future blocks anyway
449 2011-12-02 18:09:04 <gavinandresen> gmaxwell: yes, should be safe.
450 2011-12-02 18:10:06 <TD> gavinandresen: that reminds me
451 2011-12-02 18:10:12 <TD> gavinandresen: doesn't feb 1st strike you as a bit aggressive?
452 2011-12-02 18:10:30 <TD> it's safe to assume that by the time a new bitcoind is released, it'll be mid/late december
453 2011-12-02 18:10:34 <TD> people are busy over the christmas season
454 2011-12-02 18:10:35 <gmaxwell> TD: you think? I saw evidence today that it was fine.
455 2011-12-02 18:10:40 <gavinandresen> TD: I was just thinking maybe I was too conservative....
456 2011-12-02 18:10:45 <TD> then that leaves only a few weeks in january
457 2011-12-02 18:11:11 <gmaxwell> Yea. Slush and [Tycho] in the room means that we're done, basically.... assuming it works for them.
458 2011-12-02 18:11:12 <gavinandresen> TD: slush and [Tycho] and luke-jr have all expressed support, as have one or two other pools I've been talking with
459 2011-12-02 18:11:52 <gavinandresen> ... and by 'expressed support' I mean "they're starting to actually get patches and apply them to their patched bitcoinds"
460 2011-12-02 18:11:59 <luke-jr> TD: OP_EVAL is a miner-only update, for the most part
461 2011-12-02 18:12:02 <TD> right
462 2011-12-02 18:12:30 <[eval]> when it's in mainline bitcoind, that means p2pool will support it too?
463 2011-12-02 18:12:31 <luke-jr> gavinandresen: no word from BTCGuild?
464 2011-12-02 18:12:32 <gmaxwell> TD: there isn't even any risk for other miners that don't upgrade so long as they currently reject nonstandard txn.
465 2011-12-02 18:12:33 <[Tycho]> I didn't tried to apply it yet, but I'm going to, if it won't cause any problems.
466 2011-12-02 18:12:54 <TD> [Tycho]: what version are you currently running?
467 2011-12-02 18:12:59 <gavinandresen> luke-jr: no, haven't heard from them
468 2011-12-02 18:13:00 <eueueue> the next version will have export/import private key?
469 2011-12-02 18:13:02 <luke-jr> [eval]: p2pool relys on miners to choose what to support
470 2011-12-02 18:13:15 <[Tycho]> TD: I don't know, but I think it may be based on 0.3.X
471 2011-12-02 18:13:24 <luke-jr> &
472 2011-12-02 18:13:36 <luke-jr> [Tycho]: you don't maintain your pool codebase in git?
473 2011-12-02 18:13:37 <TD> [Tycho]: do you plan to ever get back on the mainline releases?
474 2011-12-02 18:13:49 <gavinandresen> [Tycho]: I'm happy to patch for you if you're comfortable bundling up the code and sending it to me...
475 2011-12-02 18:14:25 <gavinandresen> (I've back-ported to three different releases now so I'm getting pretty good at it)
476 2011-12-02 18:14:40 <[Tycho]> luke-jr: I do.
477 2011-12-02 18:16:48 <[Tycho]> The only thing I don't like about this is that GitX doesn't allows to merge .patch files in GUI
478 2011-12-02 18:17:11 <luke-jr> [Tycho]: GitX won't show you what version you forked?
479 2011-12-02 18:17:48 <luke-jr> gavinandresen: btw, in case you didn't notice, I also added maxtxfee to that pull req
480 2011-12-02 18:17:54 <luke-jr> (for forced fees)
481 2011-12-02 18:18:19 <[Tycho]> I don't know where I can check the version.
482 2011-12-02 18:18:34 <[Tycho]> I just applied some commits as needed.
483 2011-12-02 18:18:51 <gavinandresen> serialize.h should tell you the version you started with
484 2011-12-02 18:19:17 <luke-jr> [Tycho]: GitX doesn't have 'cherry-pick' either? >_<
485 2011-12-02 18:19:19 <TD> [Tycho]: what do you need? if your local mods were merged in or reimplemented in some other way, would you get back onto mainline release?
486 2011-12-02 18:19:35 <TD> just thinking forward to the next time we want new scripts whitelisted ....
487 2011-12-02 18:19:51 <[Tycho]> Why would I need to get back to the mainline ?
488 2011-12-02 18:20:13 <TD> bitcoin has lots of features that can really make it stand out above other payment systems
489 2011-12-02 18:20:18 <TD> but often they need things activated or whitelisted in the code
490 2011-12-02 18:20:18 <[Tycho]> Mostly my changes are consisting on custom getwork generation and dispatch.
491 2011-12-02 18:20:28 <[Tycho]> *of
492 2011-12-02 18:20:31 <TD> if you track mainline releases, there's no need to do lots of discussions every time new features are added
493 2011-12-02 18:20:38 <TD> you just get them "for free" by upgrading when a new release is out
494 2011-12-02 18:20:45 <TD> hmm, ok
495 2011-12-02 18:20:58 <TD> for example, at some point we'll probably want to reactivate nLockTime
496 2011-12-02 18:21:17 <TD> and replacement of transactions in the memory pool. backporting every such change to your custom branch will just be busywork.
497 2011-12-02 18:21:31 <[Tycho]> Looks like it's 32100
498 2011-12-02 18:22:23 <TD> that's pretty old
499 2011-12-02 18:22:24 <gavinandresen> that was before the src/ rename.....
500 2011-12-02 18:22:38 <[Tycho]> Did 0.3.21 contained sendmany ?
501 2011-12-02 18:22:39 <TD> [Tycho]: what do your custom getwork patches do, exactly?
502 2011-12-02 18:23:27 <gavinandresen> [Tycho]: yes, 0.3.21 had sendmany (I had to check it out to see)
503 2011-12-02 18:24:08 <[Tycho]> Also sometimes i'm thinking about implementing my own node from scratch.
504 2011-12-02 18:24:24 <TD> that's a huge pile of work. it's easy to underestimate when you read satoshis code
505 2011-12-02 18:24:39 <TD> but doing it properly involves a really large amount of careful coding. bitcoin was in development for years before satoshi released it
506 2011-12-02 18:24:51 <TD> upgrading to mainline would be the first step, at least :)
507 2011-12-02 18:25:23 <[Tycho]> I don't like the fact that there is only one client available.
508 2011-12-02 18:25:40 <[Tycho]> It's just not "decentralized" enough :)
509 2011-12-02 18:26:32 <TD> haha :) well the software isn't the problem. your reimplementation would have to work very similarly anyway
510 2011-12-02 18:26:38 <TD> the biggest centralization problem we have now is the pools!
511 2011-12-02 18:26:47 <TD> there's only a small number of "voters" who matter
512 2011-12-02 18:26:58 <TD> the original bitcoin designed imagined almost everyone who ran it would be a miner building their own blocks
513 2011-12-02 18:27:02 <TD> variance put an end to it
514 2011-12-02 18:27:24 <[Tycho]> Otherwise it would be harder to push serious updates.
515 2011-12-02 18:27:27 <TD> [Tycho]: have you looked at poolserverj?
516 2011-12-02 18:27:33 <[Tycho]> No, why ?
517 2011-12-02 18:27:50 <TD> i'm just wondering if it can replace your need for custom getwork patches. it scales a lot better than having miners connect directly to bitcoinds
518 2011-12-02 18:27:57 <TD> the algorithms it uses are better
519 2011-12-02 18:28:06 <TD> so you only need 1 bitcoind for many, many users
520 2011-12-02 18:28:12 <[Tycho]> My miner aren't connected directly to bitcoind.
521 2011-12-02 18:28:17 <[Tycho]> *miners
522 2011-12-02 18:28:46 <[Tycho]> Why do you think that my system is considerably worse ?
523 2011-12-02 18:29:00 <TD> it might not be. i'm just trying to figure out what your system is :)
524 2011-12-02 18:29:10 <TD> when your users do a getwork, what do they talk to, exactly?
525 2011-12-02 18:29:27 <[Tycho]> My pool.
526 2011-12-02 18:29:31 <TD> right, i meant software-wise
527 2011-12-02 18:29:36 <[Tycho]> nginx.
528 2011-12-02 18:29:53 <TD> ok. and where does it get the work from .... does an RPC to bitcoind?
529 2011-12-02 18:30:24 <[Tycho]> No, I have binary interface for this.
530 2011-12-02 18:30:46 <TD> ah ok. that's your custom getwork patches?
531 2011-12-02 18:30:53 <[Tycho]> This too.
532 2011-12-02 18:31:25 <TD> the binary interface is because it's faster than json parsing?
533 2011-12-02 18:31:34 <[Tycho]> I'm generating not a singe work at a time, but big batches.
534 2011-12-02 18:32:07 <[Tycho]> Yes. Also to avoid unnecessary connecting overhead.
535 2011-12-02 18:32:11 <TD> i see
536 2011-12-02 18:32:42 <[Tycho]> May be poolserverj is somewhat faster, but I don't think that I need to replace everything.
537 2011-12-02 18:33:00 <[Tycho]> Currently I have LOTS of spare resources.
538 2011-12-02 18:33:27 <TD> right. i think it'd be quite a lot faster actually. i guess most of your cpu cycles go on creating works, still.
539 2011-12-02 18:33:47 <TD> but my line of thinking is more like .... if you can have a solution more efficient than your current one, without any patches, then it's super easy for you to upgrade
540 2011-12-02 18:33:57 <[Tycho]> Most of my core is running on JVM too.
541 2011-12-02 18:34:01 <TD> and that means it's super easy to enable new features in bitcoin, that can do cool things like the contracts, micropayments, etc
542 2011-12-02 18:34:16 <[Tycho]> Why "without any patches" ?
543 2011-12-02 18:34:29 <TD> poolserverj sits in front of a regular, unpatched bitcoind
544 2011-12-02 18:34:33 <TD> (of the latest version)
545 2011-12-02 18:34:36 <TD> and just generates work more efficiently.
546 2011-12-02 18:35:04 <TD> so patches to the c++ aren't needed to get efficiency improvements anymore.
547 2011-12-02 18:35:17 <[Tycho]> Well, I don't think that you can decide if it's generating work more efficiently or not without knowing how i'm doing it.
548 2011-12-02 18:36:20 <[Tycho]> I know that stock bitcoind was really bad at work generation and this caused slush to have many bitcoinds running for each pool node.
549 2011-12-02 18:37:17 <TD> that's what poolserverj fixes
550 2011-12-02 18:37:28 <[Tycho]> The next thing I'm going to improve is the miner-pool protocol. But miner developers avoid this even when I'm offering them considerable rewards.
551 2011-12-02 18:37:31 <TD> bitcoind just generates a work each time a new tx is broadcast in that scheme
552 2011-12-02 18:37:44 <TD> so once every few seconds or so. not a big deal.
553 2011-12-02 18:37:49 <makomk> The catch with poolserverj is IIRC that it has a fixed payout address right now.
554 2011-12-02 18:38:06 <TD> there's at least one big mining pool using it. i forget which. btcguild?
555 2011-12-02 18:38:13 <[Tycho]> makomk: fixed generation affress
556 2011-12-02 18:38:17 <[Tycho]> makomk: fixed generation address ?
557 2011-12-02 18:38:29 <TD> so it's not a proof of concept or anything. i don't know enough about the details to discuss this point specifically.
558 2011-12-02 18:38:48 <makomk> Yeah, the address that the generate goes to is hardcoded in the config.
559 2011-12-02 18:38:53 <TD> ok
560 2011-12-02 18:38:56 <TD> it's just a big java app
561 2011-12-02 18:39:04 <TD> if [Tycho]s code is already java, then it should be quite easy to integrate, i'd hope
562 2011-12-02 18:39:04 <[Tycho]> TD, I don't have such problem, so I'm not considering switching to it.
563 2011-12-02 18:39:22 <[Tycho]> No, my code is not Java, it's just runs on JVM.
564 2011-12-02 18:39:27 <makomk> BTCGuild are using poolserverj, but they've gone PPS now so it doesn't matter that their blocks can be identified.
565 2011-12-02 18:39:41 <[Tycho]> makomk: I can do this with just one line in bitcoind source if I wanted to.
566 2011-12-02 18:40:01 <TD> sure. the goal is to avoid you needing a custom bitcoind
567 2011-12-02 18:40:12 <TD> bitcoin works best if everyone, especially miners, is on the latest version
568 2011-12-02 18:40:28 <TD> so if you can have the same efficiency you have today, or better, but with no custom patches, it makes introducing new features for the community much easier
569 2011-12-02 18:40:43 <TD> there's no need for backports to v 0.3.1 when the current version is 0.5
570 2011-12-02 18:42:40 <[Tycho]> Also I think that serious updates shouldn't happen too often.
571 2011-12-02 18:42:49 <[Tycho]> At least compatibility-breaking ones.
572 2011-12-02 18:44:04 <gmaxwell> [Tycho]: they shouldn't .. but if we need all of N people, and each of the N is 10% like to reject _any_ change because they're too busy to merge now.. then it rapidly becomes impossible to change anything ever.
573 2011-12-02 18:44:04 <[Tycho]> Hope _Fireball will get his stuff ready soon :)
574 2011-12-02 18:45:53 <TD> [Tycho]: most of the changes would be just whitelisting new scripts. not that hard.
575 2011-12-02 18:46:02 <TD> [Tycho]: but it's still easier if you just download+run (or recompile)
576 2011-12-02 18:46:59 <TD> [Tycho]: look at it another way. running the latest version is a competitive advantage for you. let's say gavin introduces a new script feature that makes Bitcoin more appealing somehow ... maybe more secure (like this one). miners will start to read that by mining on DeepBit they are causing tx delays for anyone who uses the new features. but by switching to $POOL they are making confirmation of those transactions a bit faster
577 2011-12-02 18:47:10 <TD> if they support bitcoin, or want to use those features themselves, they'll be incented to switch to another pool
578 2011-12-02 18:47:26 <TD> if mining on DeepBit is guaranteed to always be working on the latest feature set, there's no need for that
579 2011-12-02 18:47:45 <TD> so because mining on the latest version is a competitive advantage, making it easy to keep up should be worth it
580 2011-12-02 18:48:08 <TD> it doesn't have to mean "zero patches". just making sure you keep rebasing against the latest versions is enough
581 2011-12-02 18:48:09 <[Tycho]> Luckily most of my users aren't reading the forum :)
582 2011-12-02 18:49:18 <[Tycho]> Also, sometimes I'm applying new features as needed.
583 2011-12-02 18:50:03 <TD> it's probably less work for you to forward port your getwork patches than backport features.
584 2011-12-02 18:51:00 <[Tycho]> Currently I'm not declining any "new-type" TXs and not going to.
585 2011-12-02 18:53:09 <gavinandresen> The real pressure to upgrade will come when the GUI supports newfangled bitcoin addresses and always-secure wallets and your users want you to send bitcoins to the newfangled addresses for payouts
586 2011-12-02 18:53:46 <[Tycho]> "newfangled" ?
587 2011-12-02 18:54:17 <gavinandresen> Yes, see BIP 13 -- a new kind of bitcoin address to go with the new OP_EVAL txout type
588 2011-12-02 18:55:14 <gavinandresen> https://en.bitcoin.it/wiki/BIP_0013
589 2011-12-02 18:55:56 <gmaxwell> speaking of getwork changes.. is there any motion to get incremental merkle root updating in mainline?
590 2011-12-02 18:56:14 <gavinandresen> gmaxwell: patches welcome
591 2011-12-02 18:56:58 <[Tycho]> Installed a new client couple of days ago... Still downloading blocks :)
592 2011-12-02 18:56:59 <gavinandresen> that's not on my priority list, though, and in general I think a solution like poolserverj is a better approach
593 2011-12-02 18:57:09 <gmaxwell> 01:19 < denisx> with the merkletreeupdater my pushpool needs 70???sec for a getwork request
594 2011-12-02 18:57:28 <gmaxwell> I guess he's not around now to bug.
595 2011-12-02 19:01:36 <[Tycho]> gavinandresen: so what's wrong with this new address ? What special output script will it require ?
596 2011-12-02 19:02:42 <gmaxwell> Nothing is 'wrong' with it. It has a different output script. (matching the hash of the input script that is allowed to spend it)
597 2011-12-02 19:03:42 <[Tycho]> Don't see any problems then. Also, I'm sending payments via another nodes, not the mining ones.
598 2011-12-02 19:05:25 <gmaxwell> Ah, well, you'll have to update that one and your web interface at some point when people want payments to those addresses.
599 2011-12-02 19:10:49 <[Tycho]> Looks a couple of minutes work for m.
600 2011-12-02 19:11:05 <[Tycho]> Just add new version to allowed ones.
601 2011-12-02 19:11:35 <[Tycho]> Also, I really don't think that all nodes running exactly same software version is good for the network.
602 2011-12-02 19:12:07 <gmaxwell> it isn't but the old bitcoin versions are hardly different enough to make a real improvement there.
603 2011-12-02 19:17:59 <[Tycho]> Well, I would prefer another client at all, not the old version :)
604 2011-12-02 19:18:13 <[Tycho]> (not for me, but for some other nodes)
605 2011-12-02 19:18:54 <luke-jr> [Tycho]: if you're gonna fork, do it right :P
606 2011-12-02 19:19:06 <[Tycho]> No, I'm not going to.
607 2011-12-02 19:19:19 <[Tycho]> Only writing from scratch if even :)
608 2011-12-02 19:19:52 <[Tycho]> Hm, automatic patch applying failed in 5 places. Have to look at it manually.
609 2011-12-02 19:21:40 <luke-jr> wumpus: something's wrong with the build system I think; it isn't recompiling UI changes
610 2011-12-02 19:28:28 <luke-jr> ah
611 2011-12-02 19:28:32 <luke-jr> wumpus: nm, sorry
612 2011-12-02 19:52:44 <luke-jr> sipa: sipa/ipv6 seems to need a rebase :x
613 2011-12-02 20:03:43 <luke-jr> gavinandresen: hope that summary I just wrote up is useful
614 2011-12-02 20:05:05 <gavinandresen> luke-jr: hmm?  summary of what?
615 2011-12-02 20:05:30 <luke-jr> gavinandresen: stuff ACK'd for 0.6, probably-ready for 0.6, and needing review
616 2011-12-02 20:05:46 <luke-jr> gavinandresen: based on the pull request list, comments, and manually trying to merge them all
617 2011-12-02 20:05:59 <luke-jr> gavinandresen: I just sent to the -dev list
618 2011-12-02 20:06:15 <gavinandresen> ah, haven't checked email since I just walked back in the door...
619 2011-12-02 20:06:18 <luke-jr> heh
620 2011-12-02 20:06:38 <luke-jr> also pushed 'next' and 'next-test' branches to my personal repo
621 2011-12-02 20:09:37 <gavinandresen> luke-jr: thanks, that is helpful.
622 2011-12-02 20:10:23 <luke-jr> don't trust my branches though
623 2011-12-02 20:10:39 <luke-jr> I'm sitting here pondering how I managed to merge OP_EVAL onto coinbaser without doing anything
624 2011-12-02 20:14:40 <luke-jr> yeah, that failed& git apparently is willing to auto-merge that part incorrectly
625 2011-12-02 20:18:08 <luke-jr> aha, gavinandresen& you just overwrote the scriptSig after calculating the non-OP_EVAL one& >_<
626 2011-12-02 20:20:07 <gavinandresen> luke-jr: hmm?  pblock->vtx[0].vin[0].scriptSig += CScript() .... etc
627 2011-12-02 20:20:18 <gavinandresen> += is append
628 2011-12-02 20:20:23 <luke-jr> ah
629 2011-12-02 20:20:25 <luke-jr> I see
630 2011-12-02 20:22:11 <btginsb> anyone able to help with a php/API problem?
631 2011-12-02 20:28:51 <gribble> The operation succeeded.
632 2011-12-02 20:28:51 <sipa> ;;later tell luke-jr i'm working on a revised version of ipv6 support, together with some refactoring
633 2011-12-02 20:29:38 <luke-jr> &
634 2011-12-02 20:30:22 <sipa> ah, you're here :)
635 2011-12-02 20:34:15 <luke-jr> gavinandresen: fixed my 'next' branch
636 2011-12-02 20:34:30 <luke-jr> (re-merged things)
637 2011-12-02 20:37:35 <sipa> luke-jr: you're planning to maintain those -next branches?
638 2011-12-02 20:46:11 <luke-jr> sipa: not long-term
639 2011-12-02 20:46:40 <sipa> ok - i think we need something like that
640 2011-12-02 20:46:55 <sipa> so it's nice to someone at least starting such branches
641 2011-12-02 20:46:59 <sipa> *see
642 2011-12-02 20:47:10 <luke-jr> but I might end up doing it, shrug
643 2011-12-02 20:47:16 <luke-jr> just not planned, at the moment
644 2011-12-02 20:47:55 <sipa> ok
645 2011-12-02 20:54:05 <luke-jr> k, both 'next' and 'next-test' are fixed
646 2011-12-02 23:04:01 <jrmithdobbs> ;;bc,blocks
647 2011-12-02 23:04:02 <gribble> 155780
648 2011-12-02 23:34:33 <makomk> Hah. Solidcoin has a hard limit on the size of reorgs now. I seem to recall this is probably a bad idea and that's why Bitcoin doesn't do it?
649 2011-12-02 23:41:47 <gmaxwell> makomk: it's less of a bad idea with a centeral master controller exists.
650 2011-12-02 23:42:09 <gmaxwell> The problem with reorg limiting is that there is always a race right at the edge of the limit where the network can be perpetually split.
651 2011-12-02 23:43:08 <makomk> Yeah, I guess the best someone can do is get new nodes stuck on a chain prior to the block where RealSolid fixed the gaping security hole.
652 2011-12-02 23:43:19 <gmaxwell> e.g. you isolate a client (via attack or a natural outage) stuff it with some happyfun blocks and now it will never rejoin the real network... you work it down to a nice low difficulty and you have a pet node.
653 2011-12-02 23:43:28 <gmaxwell> oh is it no longer possible to just copy the trust transactions? :)
654 2011-12-02 23:43:59 <makomk> Yeah, as of block 91500. He did some weird hack to stick a signature of the block hash in the scriptSig of the generate.
655 2011-12-02 23:45:16 <gmaxwell> aww
656 2011-12-02 23:45:48 <makomk> How'd you find out about that, out of interest?
657 2011-12-02 23:46:19 <gmaxwell> ... People talk, you know.
658 2011-12-02 23:46:29 <gmaxwell> I was kinda hoping to see someone rewrite it from the start.
659 2011-12-02 23:47:12 <makomk> Heh. I haven't even heard any evidence of double spending yet. Besides, he has block checkpoints.
660 2011-12-02 23:48:03 <gmaxwell> It would have been somewhat hard to do an interesting double spend attack, unfortunately, because fairly few people seem to have large amounts of SC
661 2011-12-02 23:48:12 <gmaxwell> and none were willing to loan any when I went asking.
662 2011-12-02 23:48:25 <makomk> Ah, that explains it.
663 2011-12-02 23:49:09 <gmaxwell> And splitting all those trust blocks would get noticed by RS when his coin went away, I assume, so you couldn't use that fact to mine a fork cheaply.
664 2011-12-02 23:49:25 <makomk> I was wondering why there hadn't been one yet; thought for a while I must've been imagining the hole.
665 2011-12-02 23:55:24 <makomk> Also, it looks like an attacker managed to make off with the CPF payments for at least a week before someone else noticed it by accident, so I think you're over-estimating how observant RS is.