1 2012-03-18 00:00:33 <gmaxwell> luke-jr: the plan for that is get clients to upgrade to bip16 supporting code.
  2 2012-03-18 00:00:51 <luke-jr> lol
  3 2012-03-18 00:01:02 <luke-jr> gmaxwell: i c
  4 2012-03-18 00:01:37 <gmaxwell> I mean I think it's the best that can be done other beyond having a supermajority of hash power, which we do.
  5 2012-03-18 00:01:59 <gmaxwell> (or at least we do if people weren't confused into thinking it was just a vote and were putting that in their coinbase without the support)
  6 2012-03-18 00:02:23 <luke-jr> FWIW, 0.3.23.eligius: https://bitcointalk.org/index.php?topic=69225.0
  7 2012-03-18 00:26:42 <mcorlett> Could an attacker with 51% or more of the network extort miners, and say, for example, "send 40 BTC from your next block to address X, or I won't mine on top of it"?
  8 2012-03-18 00:27:15 <mcorlett> ("send" as in "include in the generation transaction")
  9 2012-03-18 00:27:16 <[Tycho]> Yes.
 10 2012-03-18 00:27:18 <gjs278> an attacker with 51% could literally kill you for bitcoins
 11 2012-03-18 00:33:11 <gmaxwell> Attn Windows Bitcoin GUI users: There is a potential security hole fixed by 0.5.3.1 / 0.6.0rc4. PLEASE UPGRADE. https://bitcointalk.org/index.php?topic=69120.0
 12 2012-03-18 00:34:31 <mcorlett> gmaxwell: Is there consensus as to when you will be announcing the fix publicly?
 13 2012-03-18 00:35:10 <jrmithdobbs> mcorlett: it's already available
 14 2012-03-18 00:35:42 <mcorlett> jrmithdobbs: Is that so? Where can I find it?
 15 2012-03-18 00:36:53 <jrmithdobbs> in 0.5.3.1 and 0.6.0rc4?
 16 2012-03-18 00:37:12 <mcorlett> Those are compiled. I want the source.
 17 2012-03-18 00:37:20 <jrmithdobbs> um
 18 2012-03-18 00:37:33 <jrmithdobbs> all builds are done based off what's in github, so if there are binaries the source is already available.
 19 2012-03-18 00:37:41 <nanotube> jrmithdobbs: that's not the case.
 20 2012-03-18 00:37:45 <nanotube> in this particular case
 21 2012-03-18 00:37:57 <nanotube> it seems they've built the fixed binaries without pushing the source of the fix to github
 22 2012-03-18 00:38:00 <nanotube> for 'extra protection'
 23 2012-03-18 00:38:12 <nanotube> so mcorlett poses a valid question
 24 2012-03-18 00:38:15 <nanotube> afaik
 25 2012-03-18 00:38:18 <jrmithdobbs> err wtf
 26 2012-03-18 00:38:40 <jrmithdobbs> whose cockimamey idea was that crap? you mean i'm building vulnerable verions?
 27 2012-03-18 00:39:00 <mcorlett> jrmithdobbs: Yes to the latter question.
 28 2012-03-18 00:39:13 <mcorlett> (Only Windows + Qt, though.)
 29 2012-03-18 00:39:25 <mcorlett> bitcoind and Qt on Mac/Linux are safe.
 30 2012-03-18 00:39:26 <luke-jr> jrmithdobbs: if you're building for windows&
 31 2012-03-18 00:39:58 <jrmithdobbs> i'm aware
 32 2012-03-18 00:40:41 <gmaxwell> nanotube: 0.6.0rc4 is on github.
 33 2012-03-18 00:41:00 <jrmithdobbs> i thought so, cause the version got bumped last pull i did so the error message would go away
 34 2012-03-18 00:41:09 <nanotube> gmaxwell: ah ok, so it's just the 0.5.3.1 that's missing?
 35 2012-03-18 00:41:23 <gmaxwell> 0.5.3.1 is not simply because the only fix in that version is the relevant one.
 36 2012-03-18 00:41:42 <luke-jr> gmaxwell: someone building 0.6.0rc4 from git will not get the fix
 37 2012-03-18 00:41:47 <jrmithdobbs> it was this wasn't it?
 38 2012-03-18 00:41:53 <jrmithdobbs> https://github.com/bitcoin/bitcoin/issues/901
 39 2012-03-18 00:42:12 <mcorlett> I thought so as well, but that's pretty old.
 40 2012-03-18 00:42:22 <gmaxwell> jrmithdobbs: we're not discussing the specifics right now.
 41 2012-03-18 00:43:38 <luke-jr> ;;tell jrmithdobbs FYI, building 0.6.0rc4 from git will *not* get the fix
 42 2012-03-18 00:43:45 <luke-jr> did that work?
 43 2012-03-18 00:44:10 <gribble> jrmithdobbs: FYI, building 0.6.0rc4 from git will *not* get the fix
 44 2012-03-18 00:44:10 <luke-jr> ;;echo jrmithdobbs: FYI, building 0.6.0rc4 from git will *not* get the fix
 45 2012-03-18 00:44:16 <jrmithdobbs> 20:43 [Freenode] [gribble(~gribble@unaffiliated/nanotube/bot/gribble)] luke-jr wants me to tell you: FYI, building 0.6.0rc4 from git will *not* get the fix
 46 2012-03-18 00:44:27 <luke-jr> guess so
 47 2012-03-18 00:45:57 <jrmithdobbs> so you're not providing a fix to anyone that doesn't run official binaries? that seems kind of backwards.
 48 2012-03-18 00:46:40 <luke-jr> jrmithdobbs: all Windows users run official binaries, no?
 49 2012-03-18 00:48:13 <freewil> HN: "Bitcoin devs conspire to steal Windows users' bitcoins" ;)
 50 2012-03-18 00:52:19 <gmaxwell> jrmithdobbs: ever used gitian before?
 51 2012-03-18 00:53:40 <jrmithdobbs> no because it doesn't work on a platform i'm willing to install
 52 2012-03-18 00:54:03 <gmaxwell> jrmithdobbs: you're not willing to run ubuntu in a VM? tisk tisk.
 53 2012-03-18 00:54:16 <luke-jr> gmaxwell: to be fair, most motherboards won't support that setup :p
 54 2012-03-18 00:54:22 <jrmithdobbs> gmaxwell: i'm not willing to run ubuntu on anything an employer doesn't force me to
 55 2012-03-18 01:17:25 <devrandom> luke-jr: I had experienced flakiness with backing images before, but if they work well we could use that
 56 2012-03-18 01:17:45 <luke-jr> odd, never had problems with it here, so long as the backing img didn't change
 57 2012-03-18 01:18:20 <devrandom> it was years ago...
 58 2012-03-18 01:33:11 <gmaxwell> Attn Windows Bitcoin GUI users: There is a potential security hole fixed by 0.5.3.1 / 0.6.0rc4. PLEASE UPGRADE. https://bitcointalk.org/index.php?topic=69120.0
 59 2012-03-18 01:40:44 <doublec> github is already tagged, shouldn't the fix be inthere?
 60 2012-03-18 01:40:56 <doublec> oops responding to old log
 61 2012-03-18 01:42:01 <terry> how do i switch languages in 0.6
 62 2012-03-18 01:42:02 <doublec> I assumed 886401 was the fix
 63 2012-03-18 01:44:05 <luke-jr> terry: it's an OS thing
 64 2012-03-18 01:44:27 <terry> p.s. the swedish translation is terrible
 65 2012-03-18 01:44:43 <luke-jr> so improve it
 66 2012-03-18 01:44:56 <terry> i value my time far too much
 67 2012-03-18 01:45:16 <terry> if you're going to force me to use that terrible one, at least give me an option to change it back to english
 68 2012-03-18 01:47:09 <terry> mmmmm
 69 2012-03-18 01:47:10 <terry> -lang
 70 2012-03-18 02:11:06 <gribble> New news from bitcoinrss: ali1234 opened pull request 947 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/947>
 71 2012-03-18 02:33:11 <gmaxwell> Attn Windows Bitcoin GUI users: There is a potential security hole fixed by 0.5.3.1 / 0.6.0rc4. PLEASE UPGRADE. https://bitcointalk.org/index.php?topic=69120.0
 72 2012-03-18 03:33:11 <gmaxwell> Attn Windows Bitcoin GUI users: There is a potential security hole fixed by 0.5.3.1 / 0.6.0rc4. PLEASE UPGRADE. https://bitcointalk.org/index.php?topic=69120.0
 73 2012-03-18 03:47:51 <luke-jr> devrandom: btw, it's a real pain to gitian-build private code
 74 2012-03-18 04:14:03 <Diablo-D3> goddamnit newegg
 75 2012-03-18 04:14:06 <Diablo-D3> I dont care if its sunday
 76 2012-03-18 04:14:10 <Diablo-D3> why is my new toy not here yet
 77 2012-03-18 04:22:36 <devrandom> luke-jr: say more?
 78 2012-03-18 04:23:08 <luke-jr> devrandom: gitian seems to assume it can pull from some public git repo
 79 2012-03-18 04:23:50 <luke-jr> devrandom: to do builds of private code, I need to edit the .yml to a 10.0.2.2 location, on-target in while it's apting, ssh-keygen, and ssh-copy-id to the host
 80 2012-03-18 04:32:48 <devrandom> luke-jr: you can publish it internally with https: instead of git+ssh:
 81 2012-03-18 04:33:11 <gmaxwell> Attn Windows Bitcoin GUI users: There is a potential security hole fixed by 0.5.3.1 / 0.6.0rc4. PLEASE UPGRADE. https://bitcointalk.org/index.php?topic=69120.0
 82 2012-03-18 04:34:43 <luke-jr> devrandom: only if I install/run a webserver with signed SSL key etc
 83 2012-03-18 04:45:01 <devrandom> luke-jr: I have to go, but we can figure it out later
 84 2012-03-18 05:33:11 <gmaxwell> Attn Windows Bitcoin GUI users: There is a potential security hole fixed by 0.5.3.1 / 0.6.0rc4. PLEASE UPGRADE. https://bitcointalk.org/index.php?topic=69120.0
 85 2012-03-18 06:23:01 <ThomasV> 85.214.124.168 found 3 consecutive blocks..
 86 2012-03-18 06:25:12 <midnightmagic> maybe that's art
 87 2012-03-18 06:25:19 <Rabbit67890-0> yeah
 88 2012-03-18 06:25:42 <ThomasV> why would art not take transactions?
 89 2012-03-18 06:26:38 <Rabbit67890> i dont know?
 90 2012-03-18 06:26:48 <Rabbit67890> ask art if he does?
 91 2012-03-18 06:26:51 <midnightmagic> oh that ip doesn't do txn?
 92 2012-03-18 06:26:55 <midnightmagic> that's not art then
 93 2012-03-18 06:27:03 <[Tycho]> It's MM
 94 2012-03-18 06:31:47 <midnightmagic> ... Wolfgang M. Schmitt..
 95 2012-03-18 06:33:11 <gmaxwell> Attn Windows Bitcoin GUI users: There is a potential security hole fixed by 0.5.3.1 / 0.6.0rc4. PLEASE UPGRADE. https://bitcointalk.org/index.php?topic=69120.0
 96 2012-03-18 06:50:02 <midnightmagic> [Tycho]: are you MM? :)
 97 2012-03-18 06:50:17 <Rabbit67890> oh wow.
 98 2012-03-18 06:50:24 <Rabbit67890> i just downloaded that....
 99 2012-03-18 06:55:11 <SomeoneWeird> cee eye aye
100 2012-03-18 06:58:04 <Cory> MM?
101 2012-03-18 06:58:18 <Graet> MAssive Miner :P
102 2012-03-18 06:58:23 <Graet> Mystery Miner
103 2012-03-18 06:58:42 <Graet> anything lese rthat fits with twilight zone music :P
104 2012-03-18 06:59:02 <Cory> Oh, right.
105 2012-03-18 06:59:06 <Graet> else*
106 2012-03-18 06:59:10 <Graet> ;)
107 2012-03-18 06:59:57 <da2ce7> Graet: has your pool been hit by the MM?
108 2012-03-18 07:00:09 <Graet> hit?
109 2012-03-18 07:00:46 <Graet> http://blockchain.info/blocks/85.214.124.168
110 2012-03-18 07:00:50 <da2ce7> I don't know... dosn't it use a IP of a pool to release it's blocks?
111 2012-03-18 07:01:03 <Graet> uses that ip
112 2012-03-18 07:01:16 <Graet> a lot have been sent thru deepbit afaik
113 2012-03-18 07:01:17 <da2ce7> it has about 50% hashing speed...
114 2012-03-18 07:01:29 <Graet> 50% of what?
115 2012-03-18 07:01:57 <da2ce7> of the last 18 blocks
116 2012-03-18 07:02:18 <da2ce7> well slightly less than 50%
117 2012-03-18 07:02:30 <Cory> About 15% over the last 100.
118 2012-03-18 07:02:40 <da2ce7> hmm... wow.
119 2012-03-18 07:02:41 <Graet> it has about 15% of the hashrate according to the experts
120 2012-03-18 07:02:42 <Cory> Probably similar for last 1000.
121 2012-03-18 07:02:50 <da2ce7> that is a massive chunk of mining power.
122 2012-03-18 07:02:57 <Graet> indeed
123 2012-03-18 07:03:05 <Cory> It is. And it's slowing down confirmations.
124 2012-03-18 07:03:23 <Graet> a *lot* of ppl are worried and rumors and misinformation abound
125 2012-03-18 07:03:27 <Graet> as usual...
126 2012-03-18 07:03:37 <da2ce7> hmm...
127 2012-03-18 07:04:16 <Cory> How long has 85.214.124.168 been finding a significant percentage of the blocks?
128 2012-03-18 07:04:19 <da2ce7> providing the MM continues to mine on the chain... and dosn't carry out any 51% attack... well then we don't have any _real_ issues.
129 2012-03-18 07:04:26 <Graet> gmaxwell, has made some intelligent foru posts on the subject :)
130 2012-03-18 07:04:32 <Graet> indeed
131 2012-03-18 07:05:07 <Graet> someone made a graph, but i closed the tab this morn
132 2012-03-18 07:06:16 <da2ce7> when the BFL's start comming online... that should give the MM a run for it's hashpower.
133 2012-03-18 07:07:37 <Graet> maybe he already has them...
134 2012-03-18 07:09:17 <Graet> https://www.privateinternetaccess.com/blog/2012/03/bitcoin-war-the-first-real-threat-to-bitcoin/  even made the news, found that agin while i was l;ooking for the ngraph :P
135 2012-03-18 07:13:20 <phantomcircuit> Graet, first point is false
136 2012-03-18 07:13:29 <phantomcircuit> thus article was poorly researched
137 2012-03-18 07:13:34 <Graet> i agree
138 2012-03-18 07:13:36 <phantomcircuit> </topic>
139 2012-03-18 07:13:46 <Graet> thus sipporting my earlier statement
140 2012-03-18 07:13:48 <da2ce7> it costs no more to include transactions.
141 2012-03-18 07:13:55 <da2ce7> *close enough to 0
142 2012-03-18 07:14:17 <phantomcircuit> its clearly a pool of some kind
143 2012-03-18 07:14:21 <phantomcircuit> possibly a botnet
144 2012-03-18 07:15:24 <da2ce7> there is no way a bot-net _that_ large could excape notice
145 2012-03-18 07:15:27 <SomeoneWeird> possibly
146 2012-03-18 07:15:37 <SomeoneWeird> unless someone developed a zeus module for mining
147 2012-03-18 07:18:02 <Graet> yer watched all this discussion b4, might go do something interesting :)
148 2012-03-18 07:33:11 <gmaxwell> Attn Windows Bitcoin GUI users: There is a potential security hole fixed by 0.5.3.1 / 0.6.0rc4. PLEASE UPGRADE. https://bitcointalk.org/index.php?topic=69120.0
149 2012-03-18 08:12:58 <ThomasV> what is the typical margin earned by miners?
150 2012-03-18 08:13:20 <ThomasV> I read 5% somewhere, can't remember where
151 2012-03-18 08:24:15 <[Tycho]> Can be VERY different.
152 2012-03-18 08:33:11 <gmaxwell> Attn Windows Bitcoin GUI users: There is a potential security hole fixed by 0.5.3.1 / 0.6.0rc4. PLEASE UPGRADE. https://bitcointalk.org/index.php?topic=69120.0
153 2012-03-18 08:49:56 <ThomasV> [Tycho]: very different from miner to miner?
154 2012-03-18 08:50:26 <[Tycho]> Yes.
155 2012-03-18 08:50:45 <[Tycho]> Even power cost can vary by many times from place to place.
156 2012-03-18 08:53:29 <ThomasV> it would be nice if tx fees where high enough to account for the difference between mining profitably and mining at a loss
157 2012-03-18 08:53:41 <ThomasV> but we are far from there
158 2012-03-18 08:55:36 <ThomasV> there are on average about 50 transactions per block
159 2012-03-18 08:56:29 <[Tycho]> Yes, transactions are nice.
160 2012-03-18 08:56:37 <ThomasV> if the average fee was 0.05 btc, then a miner that does not include transactions at all would have a 5% loss
161 2012-03-18 08:57:48 <[Tycho]> Depends on the TX size
162 2012-03-18 08:57:58 <[Tycho]> 0.01 per 1000 bytes would be ok
163 2012-03-18 08:58:32 <ThomasV> yes, but tx size is not relevant for what I am talking about
164 2012-03-18 08:59:14 <ThomasV> it's true that large tx have a larger storage cost, but this cost is not supported directly by the miner who eats the fee
165 2012-03-18 08:59:28 <ThomasV> it is supported by the whole network
166 2012-03-18 08:59:49 <[Tycho]> TX size may be important for miners
167 2012-03-18 09:00:04 <ThomasV> only if they reach the block size limit
168 2012-03-18 09:00:17 <ThomasV> and have to choose between transactions
169 2012-03-18 09:00:20 <[Tycho]> No
170 2012-03-18 09:00:32 <ThomasV> why?
171 2012-03-18 09:00:58 <[Tycho]> Usually big TXes contain more inputs and are more difficult to process.
172 2012-03-18 09:01:19 <ThomasV> yes
173 2012-03-18 09:02:35 <ThomasV> you are right
174 2012-03-18 09:03:30 <sipa> ecdsa verification cost or (eternal) storage cost dominates
175 2012-03-18 09:03:37 <ThomasV> but does this difficulty significantly impact cost?
176 2012-03-18 09:03:53 <[Tycho]> ThomasV: yes.
177 2012-03-18 09:04:41 <ThomasV> I thought that once you have verified a tx, the major cost comes from hashing
178 2012-03-18 09:04:56 <sipa> hashing is not a cost
179 2012-03-18 09:05:02 <ThomasV> the tx verification needs to be performed only once
180 2012-03-18 09:05:15 <[Tycho]> There are other things that depend on block size.
181 2012-03-18 09:05:18 <ThomasV> sipa: huh?
182 2012-03-18 09:05:32 <sipa> well, it is, but it is one that is not required by the transaction
183 2012-03-18 09:05:56 <ThomasV> sipa: sure. but that's precisely my point
184 2012-03-18 09:06:00 <sipa> it will happen anyway, at the economically feasible rate
185 2012-03-18 09:06:37 <ThomasV> my point is that it is currently economically meaningful to just hash, and include zero tx in your block
186 2012-03-18 09:06:47 <sipa> sure
187 2012-03-18 09:07:02 <ThomasV> I am wondering how high tx fees have to get in order to change that
188 2012-03-18 09:08:12 <ThomasV> for example, if tx fees were 5% of the reward, would it be enough?
189 2012-03-18 09:10:48 <da2ce7> providing there is no 51% attack... it is a self-correcting system... People will get anoyed with long time to confirm transactions... and will start to include more fees.
190 2012-03-18 09:11:19 <da2ce7> then there is an compeditive advantage to those miners who include transactions... whatever the marginal cost is in verifiying them.
191 2012-03-18 09:12:49 <ThomasV> yes, but currently the competitive advantage is not there
192 2012-03-18 09:13:40 <da2ce7> so that is what we are seeing... people are quite happy to trade low fees for slightly longer verification times.
193 2012-03-18 09:13:42 <ThomasV> I am just trying to estimate what average tx fee is needed for that competitive advantage to exist and to be meaningful
194 2012-03-18 09:13:51 <da2ce7> at some point it will even out.
195 2012-03-18 09:14:43 <da2ce7> ThomasV: I don't think there is a fixed 'cost' to that will make NO block contain only 1 tx... some nodes process the transctions already, so including them in the block is no aditional cost.
196 2012-03-18 09:15:21 <[Tycho]> Sometimes I do 1Tx blocks too :)
197 2012-03-18 09:17:20 <da2ce7> also if pools start not processing transactions... it is likely that the users will hop to a different pool... Because each miner _enjoys_ having very low fee transctions.
198 2012-03-18 09:20:10 <ThomasV> da2ce7: sure, but suppose someone wants to attack the network, trying to slow down transactions. in the current situation, such an attack is profitable, because you can sell your 50btc to pay for your expenses. my question is, what is the amount of fees that is needed so that such an attack is no longer subsidized, but starts to cost
199 2012-03-18 09:20:55 <da2ce7> ThomasV: you are not attacking the network unless you purposely ophan other blocks with a 51% attack.
200 2012-03-18 09:21:10 <da2ce7> there is no 'fair' or 'unfair' play otherwise.
201 2012-03-18 09:22:11 <ThomasV> da2ce7: from a user point of view, someone down transactions can be considered as an attack
202 2012-03-18 09:23:28 <da2ce7> ThomasV: no, becasue that user didn't pay for the "attackers" hashing.  Rarther the "attacker" (supose it isn't doing a 51% attack), is just adding aditional strength to the network.
203 2012-03-18 09:23:54 <da2ce7> making the users transctions more secure... _once_ they get included in a block.
204 2012-03-18 09:25:05 <ThomasV> yes, if 51% is the only threat that you worry about
205 2012-03-18 09:27:04 <da2ce7> even if the "attacker" had 99% of the hashing power... the network would be fine... and very secure, providing the "attacker" didn't orphan the 1/100 blocks that the rest of the network finds (that there would be huge compition to get into, thus attracting high fees).
206 2012-03-18 09:27:08 <Graet> luke set the precedent with um coiledcoin or something, mine ALL the blocks but include no txn ;)
207 2012-03-18 09:27:57 <da2ce7> Graet: yes... but he ophaned other blocks...
208 2012-03-18 09:28:44 <ThomasV> if you have 51%, nothing prevents you from orphaning blocks
209 2012-03-18 09:29:54 <Graet> he was doing a 100% attack i thought :P
210 2012-03-18 09:31:54 <da2ce7> ThomasV: yes... but what happens if I'm some mad mathamatitian who works out how to do sha256 in one millionth of the time... so I mine the network, (keeping the flaw in sha256 secert), however don't ophan any competing blocks.
211 2012-03-18 09:32:18 <da2ce7> what I'm doing in-fact is just making the network more secure.
212 2012-03-18 09:33:11 <gmaxwell> Attn Windows Bitcoin GUI users: There is a potential security hole fixed by 0.5.3.1 / 0.6.0rc4. PLEASE UPGRADE. https://bitcointalk.org/index.php?topic=69120.0
213 2012-03-18 09:36:16 <ThomasV> da2ce7: the current 'mystery miner' does not seem to be trying to orphan blocks. he mined 171675. then slush mined 171676. then he mined 171677. this means that when slush published his block, he spent his hashing power finding 171677, not to orphan 171676.
214 2012-03-18 09:37:29 <ThomasV> you can see it here: http://www.blockchain.info/blocks
215 2012-03-18 09:37:40 <da2ce7> ThomasV: yes, and the MM has less than 50% anyway. :) so maybe it is just an anon friend of bitcoin.
216 2012-03-18 09:39:32 <ThomasV> I believe this sequence means that he spent his computing power on 171677 instead of trying to orphan slush's block. but I am not an expert.. perhaps it is possible to merge-mine both tasks?
217 2012-03-18 09:39:55 <ThomasV> (I don't know how merged mining works)
218 2012-03-18 09:40:41 <ThomasV> could someone who knows about it confirm?
219 2012-03-18 09:42:22 <da2ce7> https://bitcointalk.org/index.php?topic=55600.0
220 2012-03-18 09:43:02 <da2ce7> ThomasV: no... not within the same chain.
221 2012-03-18 09:43:43 <da2ce7> merged mining happens when you have two chains... you insert the root of the 2nd chain into the coinbase of the 1st.  (or mykel tree).
222 2012-03-18 09:44:10 <ThomasV> good. that's what I though
223 2012-03-18 09:44:44 <da2ce7> whenever you find a low-enough hash you publish the block you were working on... the Merged Mining chain will look completly differnt to the Bitcoin (or whatever host chain), that is used.
224 2012-03-18 09:45:51 <ThomasV> so we can be reasonably sure this MM is not trying to orphan blocks
225 2012-03-18 09:46:20 <ThomasV> or at least he was not at the time of block 171677
226 2012-03-18 09:49:36 <da2ce7> yes... It seems like the MM isn't atempting to orphan blocks atm... However it dosn't make sence to, unless you have a clear 51% of the network hashing power.
227 2012-03-18 09:49:43 <da2ce7> (you will make less money)...
228 2012-03-18 09:50:35 <theorbtwo> da2ce7: It's also arguable that for most people, you'll get more money making bitcoin not fall apart if you have more then 51%.
229 2012-03-18 09:51:39 <ThomasV> unless your goaal is to make it fall apart :)
230 2012-03-18 09:51:57 <da2ce7> theorbtwo: however at some point it dosn't make sence not to include the higher-fee transactions in you blocks, if you are not looking to make bitocin fall apart.
231 2012-03-18 09:53:35 <ThomasV> even if you are trying to make it fall apart, you would remain covert and act normal until you have 51%
232 2012-03-18 09:54:18 <Graet> why? being out oin the open is causing much discussion and fear
233 2012-03-18 09:54:33 <da2ce7> ThomasV: yes... you would maximize proffits so that you can extract as much money from bitcoin before you distoyed it.
234 2012-03-18 09:54:51 <ThomasV> Graet: so that you can still resell your coins, and fund your hardware
235 2012-03-18 09:55:18 <da2ce7> Graet: is also make people think about possible mitergations, and gives people inpouluse to code aganst an possible attack.
236 2012-03-18 09:55:31 <Graet> if your goal is to destriy bitcoin causing fear and making ppl leave will reduce your hardware costs
237 2012-03-18 09:57:07 <da2ce7> Remember, in-theroy... Users can choose whatever fork they want... if there is a 51% attack, there is nothing wrong with a user forcing his or her client to only accept the chain that deepbit, slush, and others are mining on.
238 2012-03-18 09:57:28 <da2ce7> Also, Pools and other miners are free to choose what chain they mine on... even if it is the shorter chain.
239 2012-03-18 09:58:02 <slothbag> does anyone know if there is a virtual machine image or something like that for building statically linked bitcoin-qt builds? particularly windows builds?
240 2012-03-18 09:58:26 <da2ce7> while it may be possible to have a 51% attack... less "pure" forms of bitcoin can make it much much harder to sustain such an attack.
241 2012-03-18 09:58:50 <ThomasV> da2ce7: good point
242 2012-03-18 10:01:55 <TuxBlackEdo> that's pretty cool idea da2ce7
243 2012-03-18 10:02:03 <TuxBlackEdo> i would like to see this implemented
244 2012-03-18 10:05:50 <TuxBlackEdo> this "choose your own fork" feature would allow fork causing code to be implemented (and would allow the clients to properly push changes to all forked blockchains)
245 2012-03-18 10:06:31 <TuxBlackEdo> i am not sure how it works now, but whatever chain is the longest is the one bitcoin will send transactions to? i might be wrong about that
246 2012-03-18 10:09:30 <da2ce7> from my analysis the security of bitcoin... even when the reward goes down to virtualy 0, reamins good... providing the attacker isn't externaly financaly motiviated.
247 2012-03-18 10:09:43 <da2ce7> *economic analysis.
248 2012-03-18 10:10:19 <da2ce7> I'm convinced that bitcoin is secure from internal attacks (eg, a party financaly motivated to gain bitcoin).
249 2012-03-18 10:11:56 <ThomasV> what is a 15% attack? it's an attack perpertrated by a dyslexic
250 2012-03-18 10:12:31 <da2ce7> ThomasV: lawl.
251 2012-03-18 10:18:16 <ThomasV> I think I am going to raise the default fee in Electrum
252 2012-03-18 10:32:40 <Eliel> ... ok no, that'd be trivially easy to flood with false signatures.
253 2012-03-18 10:33:06 <sipa> Eliel: some proof-of-stake schemes depend on that
254 2012-03-18 10:33:11 <gmaxwell> Attn Windows Bitcoin GUI users: There is a potential security hole fixed by 0.5.3.1 / 0.6.0rc4. PLEASE UPGRADE. https://bitcointalk.org/index.php?topic=69120.0
255 2012-03-18 10:45:23 <da2ce7> ThomasV: hey can you please pre-read this post for me... http://pastebin.com/3VvBraD3
256 2012-03-18 10:45:31 <da2ce7> *also anyone else is welcome to.
257 2012-03-18 10:47:32 <[Tycho]> "Dose the precise order" ?
258 2012-03-18 10:48:31 <ThomasV> da2ce7: you know that there are checkpoints in the blockchain, that are coded in the client
259 2012-03-18 10:48:44 <da2ce7> yes.
260 2012-03-18 10:48:50 <ThomasV> this means that devs are trusted for that
261 2012-03-18 10:49:00 <ThomasV> it relates to what you are saying
262 2012-03-18 10:49:23 <ThomasV> but you are thinking of something more dynamic
263 2012-03-18 10:50:35 <sipa> anyone who does not investigate the sourcecode thoroughly, is trusting the developer of his client
264 2012-03-18 10:50:48 <ThomasV> sure
265 2012-03-18 10:50:58 <da2ce7> first off:  I would have every pool and major miner optionally include a cryptographic signature in the blocks that they produce.
266 2012-03-18 10:51:28 <sipa> using which key?
267 2012-03-18 10:51:54 <da2ce7> sipa: dosn't matter... they can choose a 'mining signing key'
268 2012-03-18 10:51:55 <ThomasV> da2ce7: but then bitcoin might become a closed "club"
269 2012-03-18 10:52:08 <ThomasV> being open is nice too
270 2012-03-18 10:52:25 <da2ce7> ThomasV: yes... but all this only comes into play... IF an 51% attack happens.
271 2012-03-18 10:52:53 <ThomasV> you can always pretend one is happening
272 2012-03-18 10:53:32 <da2ce7> ThomasV: no... it is very ovious when an attacker starts ophaning other blocks.. purposely.
273 2012-03-18 10:54:55 <da2ce7> eg... at least the bitcoin client can show a warning:  such ash "Warning: none of the last 100 blocks were generated by any of the 'common miners'"
274 2012-03-18 10:54:58 <da2ce7> *as
275 2012-03-18 10:55:22 <sipa> i am not sure that's the responsability of a reference client
276 2012-03-18 10:55:33 <sipa> (but maybe of alternative clients if they wish)
277 2012-03-18 10:55:49 <ThomasV> yes, but the decision should remain with the human, not the clien
278 2012-03-18 10:56:07 <ThomasV> (the decision of not following the longest chain in that case)
279 2012-03-18 10:57:00 <da2ce7> sipa: I don't know the best way for miners to sign their blocks in a standard way... that isn't my expertise... but I do believe it would be a useful feature& even if the reference client chooses not to make use of it.
280 2012-03-18 10:57:49 <sipa> some miners do put a 'signature' in their blocks' coinbases
281 2012-03-18 10:58:06 <[Tycho]> Plain signature can be forged
282 2012-03-18 10:58:10 <sipa> (just a marker text, not a signature in the cryptographic sense)
283 2012-03-18 10:58:37 <sipa> an ecdsa signature requires at least 64 bytes
284 2012-03-18 10:58:47 <[Tycho]> Sadly the coinbase TX doesn't allows more inputs, otherwise that would be very easy
285 2012-03-18 10:58:52 <sipa> coinbase space is expensive
286 2012-03-18 10:59:11 <[Tycho]> Just a 0 input from pool's address can work as a signature.
287 2012-03-18 10:59:22 <da2ce7> well whatever way is best... it needs to be cyptographicaly secure.
288 2012-03-18 11:02:13 <[Tycho]> I know some other simple methods, but that would require OOB communication and this is not cool.
289 2012-03-18 11:03:08 <sipa> What is wrong with OOB communication?
290 2012-03-18 11:03:27 <[Tycho]> I don't like it.
291 2012-03-18 11:03:37 <sipa> Do you want to replace the internet with Bitcoin's P2P network? That's not what it was intended for.
292 2012-03-18 11:03:43 <[Tycho]> Yes.
293 2012-03-18 11:04:15 <sipa> I see no reason why, expect "it's already here, we don't need any other infrastructure."
294 2012-03-18 11:04:22 <sipa> *except
295 2012-03-18 11:04:41 <[Tycho]> This too. Also it's secure.
296 2012-03-18 11:04:51 <sipa> It is very unsecure.
297 2012-03-18 11:04:55 <sipa> The whole world can see it.
298 2012-03-18 11:05:08 <[Tycho]> Not in that meaning
299 2012-03-18 11:05:22 <sipa> In what sense is it secure?
300 2012-03-18 11:07:11 <sipa> Eventually you end up with TCP/IP encapsulated in embedded data of bitcoin transactions, and all network traffic ever is recorded in the block chain.
301 2012-03-18 11:07:24 <sipa> (I exaggerate, but that's the ultimum)
302 2012-03-18 11:07:24 <[Tycho]> Why ?
303 2012-03-18 11:07:57 <sipa> You tell me :)
304 2012-03-18 11:08:51 <sipa> My opinion is: the bitcoin p2p should not be used for anything that doesn't require validation by the network.
305 2012-03-18 11:08:54 <sipa> *network
306 2012-03-18 11:12:12 <vragnaroda> That's sensible.
307 2012-03-18 11:12:54 <[Tycho]> People like you stop development of green-address-based systems :)
308 2012-03-18 11:13:20 <sipa> Did I develop such systems?
309 2012-03-18 11:13:31 <sipa> Ah, yes.
310 2012-03-18 11:14:19 <da2ce7> sipa: https://bitcointalk.org/index.php?topic=55600.msg807686#msg807686
311 2012-03-18 11:14:23 <da2ce7> that is how I would deal with it.
312 2012-03-18 11:14:53 <sipa> It may be tempting to use it for other purposes, such as simplicity (we have communication with that P2P network anyway) or anonimity (I don't need to disclose the destination, he will receive it anyway in a broadcast network), but I believe better solutions are possible for both.
313 2012-03-18 11:15:40 <TD> this is the meet-in-the-middle pubsub system>?
314 2012-03-18 11:16:59 <da2ce7> TD: it is a system that hopefully will never need to be used.
315 2012-03-18 11:17:26 <sipa> TD: i was arguing with [Tycho] who believes out-of-band communication is "not cool".
316 2012-03-18 11:17:28 <TD> i've thought it might be useful as a way to bootstrap other systems. avoids the need to reimplement peer discovery. but yes, i see the argument against it
317 2012-03-18 11:17:33 <da2ce7> however it would be nice to have... It at least works as a contingency plan
318 2012-03-18 11:33:11 <gmaxwell> Attn Windows Bitcoin GUI users: There is a potential security hole fixed by 0.5.3.1 / 0.6.0rc4. PLEASE UPGRADE. https://bitcointalk.org/index.php?topic=69120.0
319 2012-03-18 12:30:36 <[Tycho]> Wow, nice try :) https://blockchain.info/block-index/195353/0000000000000a64d9bffef38ff0d86167a6b8c34a5acc874c878a24fa19daf5
320 2012-03-18 12:32:03 <luke-jr> [Tycho]: ?
321 2012-03-18 12:33:05 <[Tycho]> A non-merged mining block relayed trough my node, containing lots of my free TXes (1VayNert), but in fact not mined by me.
322 2012-03-18 12:33:11 <gmaxwell> Attn Windows Bitcoin GUI users: There is a potential security hole fixed by 0.5.3.1 / 0.6.0rc4. PLEASE UPGRADE. https://bitcointalk.org/index.php?topic=69120.0
323 2012-03-18 12:33:23 <[Tycho]> MM's new tactic ? :)
324 2012-03-18 12:48:52 <vragnaroda> [Tycho]: lol
325 2012-03-18 12:49:39 <kinlo> safe mode is disabling listtransactions, any way to bypass that?
326 2012-03-18 12:49:49 <kinlo> running 0.6.0rc4 on testnet
327 2012-03-18 12:52:08 <sipa> why are you in safe mode?
328 2012-03-18 12:52:24 <kinlo> no idea
329 2012-03-18 12:52:38 <sipa> how many blocks are you at?
330 2012-03-18 12:52:40 <kinlo> just upgraded to 0.6.0rc4, started it, tried listtransactions and it refused
331 2012-03-18 12:52:50 <kinlo> 47967
332 2012-03-18 12:52:52 <sipa> does getinfo report an error?
333 2012-03-18 12:52:55 <kinlo> yes
334 2012-03-18 12:53:00 <sipa> oh, testnet
335 2012-03-18 12:53:05 <kinlo> yes testnet :)
336 2012-03-18 12:53:18 <sipa> yes, possible, people are still mining the old testnet chains
337 2012-03-18 12:53:40 <sipa> if those are longer, the client switches to safe mode
338 2012-03-18 12:53:43 <kinlo> I see blockexplorer is way ahaid of me
339 2012-03-18 12:54:07 <kinlo> so, I just need to wait until my client uses the correct chain?
340 2012-03-18 12:54:19 <kinlo> what's the number of blocks on the testnet on the "main" chain?
341 2012-03-18 12:54:26 <kinlo> ie the chain I must be on with 0.6.x
342 2012-03-18 12:55:47 <sipa> try -connect='ing to me? i have 49967 blocks
343 2012-03-18 12:55:55 <sipa> 80.200.41.155
344 2012-03-18 12:57:30 <kinlo> debug log is now full of errors so that must have done something
345 2012-03-18 12:57:44 <kinlo> reorganize failed
346 2012-03-18 12:57:44 <sipa> show me one
347 2012-03-18 12:57:54 <sipa> can you paste some lines around that error?
348 2012-03-18 12:58:27 <kinlo> http://pastebin.com/Y5gkk5GH
349 2012-03-18 12:59:23 <kinlo> but as the number of blocks it goes back is increasing, doesn't that just mean he's busy orphaning all blocks that are invalid?
350 2012-03-18 12:59:53 <sipa> no, your node received a chain which it considers invalid
351 2012-03-18 13:00:02 <sipa> can you restart with -checkblocks ?
352 2012-03-18 13:00:17 <kinlo> the number of Postponing reconnects is increasing
353 2012-03-18 13:00:19 <kinlo> but I'll restart
354 2012-03-18 13:00:25 <sipa> that's normal, it'll go up to 499
355 2012-03-18 13:00:35 <sipa> but you can stop it
356 2012-03-18 13:02:09 <kinlo> after restaring it with checkblocks it just continues with the same output
357 2012-03-18 13:09:28 <kinlo> sipa: any chance on removeprivkey ending up in 0.6.x?
358 2012-03-18 13:09:52 <sipa> kinlo: no
359 2012-03-18 13:10:02 <kinlo> just compared the changes on 0.6, very nice, I can throw away most patches I apply to my bitcoin
360 2012-03-18 13:10:17 <sipa> removeprivkey is
361 2012-03-18 13:10:22 <sipa> quite dangerous
362 2012-03-18 13:10:27 <kinlo> ic
363 2012-03-18 13:10:52 <kinlo> I never used it - but it looked like a normal addition to the other key management functions
364 2012-03-18 13:11:12 <sipa> it's certainly useful in certain cases, but certainly in combination with people using the accounts feature it will almost certainly not do what you want
365 2012-03-18 13:11:38 <sipa> (income from accounts to a removed address is removed, for example, but spendings from that account aren't)
366 2012-03-18 13:12:09 <kinlo> it can indeed become confusing
367 2012-03-18 13:13:26 <sipa> i believe i overused the word 'certainly' in that senstence
368 2012-03-18 13:13:30 <sipa> sentence
369 2012-03-18 13:14:28 <kinlo> :p
370 2012-03-18 13:15:03 <sipa> for certain
371 2012-03-18 13:15:53 <sipa> ok, i rebuilt my entire testnet block database; i only have 46722 blocks left myself
372 2012-03-18 13:27:51 <kinlo> Postponing 705 reconnects
373 2012-03-18 13:28:10 <kinlo> still reorganizing, way beyond the 499 you said
374 2012-03-18 13:28:58 <sipa> I'm trying to think how that is possible - but with the frequent network rule changes on testnet there are many things to consider :)
375 2012-03-18 13:29:26 <kinlo> :)
376 2012-03-18 13:29:46 <sipa> Still, i have now a 0.6.0rc4 node with a testnet chain of 49969 blocks.
377 2012-03-18 13:33:11 <gmaxwell> Attn Windows Bitcoin GUI users: There is a potential security hole fixed by 0.5.3.1 / 0.6.0rc4. PLEASE UPGRADE. https://bitcointalk.org/index.php?topic=69120.0
378 2012-03-18 14:01:44 <tomoj> do the transactions in a block include the standard message header, or do the start at the transaction data format version?
379 2012-03-18 14:02:14 <sipa> tomoj: 1) no 2) not sure what you mean
380 2012-03-18 14:03:42 <tomoj> at the end of the block where you have a varint and then n transactions, are the transactions exactly the payload from the tx message?
381 2012-03-18 14:04:13 <sipa> afaik yes
382 2012-03-18 14:05:07 <sipa> the message header is only sent at the start of messages; if the tx is a message, then yes it will be prefixed by a header; if it is part of something else, then that something else is prefixed
383 2012-03-18 14:33:11 <gmaxwell> Attn Windows Bitcoin GUI users: There is a potential security hole fixed by 0.5.3.1 / 0.6.0rc4. PLEASE UPGRADE. https://bitcointalk.org/index.php?topic=69120.0
384 2012-03-18 15:26:53 <t7> can i install new windows version over old one?
385 2012-03-18 15:28:05 <tcatm> t7: yes
386 2012-03-18 15:28:21 <t7> i swear i managed to crash bitcoin-qt before
387 2012-03-18 15:28:26 <t7> just using rpc command
388 2012-03-18 15:28:31 <t7> commands*
389 2012-03-18 15:33:11 <gmaxwell> Attn Windows Bitcoin GUI users: There is a potential security hole fixed by 0.5.3.1 / 0.6.0rc4. PLEASE UPGRADE. https://bitcointalk.org/index.php?topic=69120.0
390 2012-03-18 15:47:50 <t7> whats the advantage of litecoin's mining method?
391 2012-03-18 15:49:34 <forrestv> t7, botnets are more profitable
392 2012-03-18 15:50:08 <t7> im not sure if thats a good thing or not
393 2012-03-18 15:50:50 <t7> i mean it should be pretty easy to trace a botnet owner if he set up a mining pool
394 2012-03-18 15:50:56 <t7> he/she
395 2012-03-18 16:00:59 <Slix`> What's litecoin?
396 2012-03-18 16:33:11 <gmaxwell> Attn Windows Bitcoin GUI users: There is a potential security hole fixed by 0.5.3.1 / 0.6.0rc4. PLEASE UPGRADE. https://bitcointalk.org/index.php?topic=69120.0
397 2012-03-18 16:45:19 <andytoshi> Slix`: litecoin is an alternate blockchain that uses the scrypt hashing method for proof-of-work
398 2012-03-18 16:45:34 <andytoshi> it is a much more difficult hash and does not give advantage to GPU's
399 2012-03-18 16:45:50 <andytoshi> the goal is to improve decentralization by not requiring massive hardware setups to mine
400 2012-03-18 16:46:21 <andytoshi> but OTOH, deliberately avoiding the use of specialized hardware, weakens the network power
401 2012-03-18 16:46:46 <andytoshi> a further difference is that the blocks come more often (2.5 min IIRC, versus 10 minutes with bitcoin)
402 2012-03-18 16:46:57 <andytoshi> so it may also be better-suited to quick transactions that do not need heavy security
403 2012-03-18 16:47:24 <andytoshi> though IMHO 2.5 mins is still too long for most POS applications
404 2012-03-18 17:16:22 <luke-jr> Slix`: what andytoshi got wrong is that scrypt does NOT avoid the use of specialized hardware, only commodity hardware
405 2012-03-18 17:16:45 <luke-jr> Slix`: Litecoin is basically just another scam-coin
406 2012-03-18 17:16:47 <Diablo-D3> nothing can avoid the use of special hardware
407 2012-03-18 17:16:51 <luke-jr> Diablo-D3: exactly
408 2012-03-18 17:17:05 <Diablo-D3> infact, the harder you make it, the more special hardware looks better
409 2012-03-18 17:17:07 <Diablo-D3> ALSO
410 2012-03-18 17:17:11 <Diablo-D3> scrypt is NOT anti-gpu
411 2012-03-18 17:17:18 <Diablo-D3> which was the original selection criteria
412 2012-03-18 17:20:45 <tomoj> dns seeding is just sending addr reqs to hardcoded hostnames?
413 2012-03-18 17:21:47 <gmaxwell> tomoj: Yes, though the queried names run special nameservers that return known good nodes.  The only purpose of seeding is to find out some nodes when you known none, bootstrapping.
414 2012-03-18 17:23:01 <gmaxwell> tomoj: Once you get one good node you can learn of more. There is also a set of a few hundred nodes baked into the software used as a last resort, but it falls out of date quickly, so if it depended only on that getting connected would take a long time.
415 2012-03-18 17:23:25 <tomoj> pnSeed?
416 2012-03-18 17:26:08 <gmaxwell> Yes.
417 2012-03-18 17:26:46 <tomoj> thanks
418 2012-03-18 17:33:11 <gmaxwell> Attn Windows Bitcoin GUI users: There is a potential security hole fixed by 0.5.3.1 / 0.6.0rc4. PLEASE UPGRADE. https://bitcointalk.org/index.php?topic=69120.0
419 2012-03-18 18:33:11 <gmaxwell> Attn Windows Bitcoin GUI users: There is a potential security hole fixed by 0.5.3.1 / 0.6.0rc4. PLEASE UPGRADE. https://bitcointalk.org/index.php?topic=69120.0
420 2012-03-18 18:52:55 <kinlo> any idea when 0.6 is about to be released? :)
421 2012-03-18 18:59:52 <BlueMatt> soon
422 2012-03-18 19:00:18 <BlueMatt> theres only one outstanding issue afaik
423 2012-03-18 19:33:11 <gmaxwell> Attn Windows Bitcoin GUI users: There is a potential security hole fixed by 0.5.3.1 / 0.6.0rc4. PLEASE UPGRADE. https://bitcointalk.org/index.php?topic=69120.0
424 2012-03-18 19:41:38 <luke-jr> BlueMatt: I see quite a few actually
425 2012-03-18 19:42:23 <BlueMatt> which ones?
426 2012-03-18 19:42:34 <BlueMatt> there was discussion of making 0.6rc4 final before it was even built
427 2012-03-18 19:42:41 <luke-jr> 947, 946, 936, 926, and it'd be nice to see 931 in
428 2012-03-18 19:44:02 <BlueMatt> 947: ok, that wasnt there when it was built, and isnt a regression, but yea should go in; 946: doesnt matter in the slightest; 936: not a regression; 926: already merged a while ago; 931: meh
429 2012-03-18 19:45:18 <luke-jr> s/926/928
430 2012-03-18 19:45:49 <BlueMatt> the only issue I know of doesnt have a ticket and is another reorging large chains issue
431 2012-03-18 19:46:05 <BlueMatt> 928: meh, not a regression
432 2012-03-18 19:46:25 <luke-jr> non-regression bugs are important too :p
433 2012-03-18 19:46:29 <BlueMatt> we've really been ignoring the regressions only rule for 0.6rcs because weve been in rc so long, but we are nearing the end, so...
434 2012-03-18 19:46:38 <BlueMatt> I would really prefer to follow it a bit more
435 2012-03-18 19:46:48 <luke-jr> no idea where you get that rule from
436 2012-03-18 19:47:03 <BlueMatt> weve always had that rule, or had had it on previous releases
437 2012-03-18 19:47:22 <luke-jr> bugfixes only makes sense. regressions only doesn't.
438 2012-03-18 19:47:46 <BlueMatt> simple bugfixes and regressions was the idea
439 2012-03-18 19:47:54 <BlueMatt> not complicated bugfixes unless they fix important bugs
440 2012-03-18 19:48:03 <luke-jr> IIRC all those were simple
441 2012-03-18 19:48:29 <BlueMatt> I dont see why 928 has three commits for one line...
442 2012-03-18 19:48:56 <luke-jr> Eliel: yeah, might want to squash that one & :p
443 2012-03-18 19:48:57 <BlueMatt> 931 absolutely isnt a bugfix...
444 2012-03-18 19:49:10 <BlueMatt> nor is 936
445 2012-03-18 19:49:14 <luke-jr> BlueMatt: yeah, that's why I listed it on the end as a "nice to have"
446 2012-03-18 19:49:15 <BlueMatt> 936 is additional features
447 2012-03-18 19:49:23 <luke-jr> no, 936 is BIP compliance fix
448 2012-03-18 19:49:32 <BlueMatt> thats not a bugfix
449 2012-03-18 19:49:36 <BlueMatt> thats additional features
450 2012-03-18 19:49:37 <Eliel> BlueMatt: because I don't know how to remove commits from a pullreq and I changed it :P
451 2012-03-18 19:49:47 <BlueMatt> git rebase -i upstream/master
452 2012-03-18 19:49:48 <luke-jr> Eliel: just push --force
453 2012-03-18 19:49:53 <BlueMatt> then push -f
454 2012-03-18 19:51:29 <Eliel> ok, I'll see how that works. Thank you.
455 2012-03-18 19:54:00 <Eliel> BlueMatt: it says "fatal: Needed a single revision" to the rebase.
456 2012-03-18 19:54:55 <luke-jr> Eliel: git reset --hard master ; git cherry-pick 02ace7e ; git push --force
457 2012-03-18 19:54:57 <BlueMatt> do you not have upstream as a branch?
458 2012-03-18 19:55:12 <Diablo-D3> apparently not
459 2012-03-18 19:55:16 <Diablo-D3> use git flow goddamnit
460 2012-03-18 19:55:18 <BlueMatt> git branch add https://github.com/bitcoin/bitcoin.git upstream; git fetch upstream
461 2012-03-18 19:55:39 <Eliel> I just pulled that from the repo I forked :) I'm very close to a beginner with git.
462 2012-03-18 19:55:42 <BlueMatt> sorry, git remote add ...
463 2012-03-18 19:56:20 <Diablo-D3> erm
464 2012-03-18 19:56:27 <Diablo-D3> he should already have upstream as a remote
465 2012-03-18 19:56:48 <Diablo-D3> unless he github forked it and then cloned his own repo
466 2012-03-18 19:57:01 <Eliel> Diablo-D3: yes, that's what I did.
467 2012-03-18 19:57:07 <BlueMatt> which is what most people do
468 2012-03-18 19:57:45 <Diablo-D3> I dunno, I havent been doing that lately
469 2012-03-18 19:57:54 <Diablo-D3> Ive been doing natural github latel
470 2012-03-18 19:58:35 <Diablo-D3> er
471 2012-03-18 19:58:40 <Diablo-D3> Ive been doing natural git latel
472 2012-03-18 19:59:16 <Diablo-D3> which is, ultimately, never commit into master, use cronjob to sync origin master (which is upstream) into local master
473 2012-03-18 19:59:19 <Eliel> can I somehow throw the last 3 commits out, make the change again and then push?
474 2012-03-18 19:59:28 <Eliel> luke-jr: that doesn't seem to work.
475 2012-03-18 19:59:33 <Diablo-D3> and then only commit to my own branch (named develop)
476 2012-03-18 19:59:44 <Diablo-D3> and since my repos are public, anyone can merge my changes
477 2012-03-18 20:00:20 <Eliel> luke-jr: none of those commands changes anything it seems.
478 2012-03-18 20:00:29 <Diablo-D3> http://caspar.adterrasperaspera.com/cgit/libmowgli-2.git/?h=develop
479 2012-03-18 20:00:30 <BlueMatt> Eliel: git remote add upstream https://github.com/bitcoin/bitcoin.git; git fetch upstream; git rebase -i upstream/master
480 2012-03-18 20:00:31 <BlueMatt> git push -f
481 2012-03-18 20:00:31 <Diablo-D3> like for example
482 2012-03-18 20:00:33 <Diablo-D3> vs
483 2012-03-18 20:00:38 <Diablo-D3> http://git.atheme.org/libmowgli-2/
484 2012-03-18 20:02:08 <devrandom> luke-jr: I think you can just deploy http: for git internally, no additional admin overhead.  you can also skip git completely and just deploy your code as an input.
485 2012-03-18 20:02:14 <devrandom> hi BlueMatt
486 2012-03-18 20:02:20 <Eliel> BlueMatt: all of my 3 commits are still there after that rebase.
487 2012-03-18 20:02:49 <BlueMatt> hi devrandom
488 2012-03-18 20:03:09 <BlueMatt> Eliel: you have to change the rebase command list once it pulls up your editor
489 2012-03-18 20:03:21 <BlueMatt> ie change a line to begin with f to merge that commit into the previous one
490 2012-03-18 20:03:27 <BlueMatt> and r to reword a commitmsg
491 2012-03-18 20:04:00 <Eliel> ah, ok, now it works. Thank you.
492 2012-03-18 20:04:51 <Eliel> ok, now it's just one commit.
493 2012-03-18 20:07:00 <devrandom> BlueMatt: do you need any gitian sigs from me?
494 2012-03-18 20:07:56 <BlueMatt> 0.6.0rc4 only has two, so that would be helpful (though make sure you rebuild qt-win32 first)
495 2012-03-18 20:08:28 <BlueMatt> qt-win32 isnt deterministic, but it actually doesnt turn out to matter because the bitcoin output is deterministic even with the variances in qt-win32 output
496 2012-03-18 20:09:15 <devrandom> ok
497 2012-03-18 20:09:16 <userkggy> BlueMatt: what is the issue that still need to be fixed for 0.6 final release?
498 2012-03-18 20:11:19 <BlueMatt> if you get too far behind on a fork you sometimes cant catch up
499 2012-03-18 20:33:11 <gmaxwell> Attn Windows Bitcoin GUI users: There is a potential security hole fixed by 0.5.3.1 / 0.6.0rc4. PLEASE UPGRADE. https://bitcointalk.org/index.php?topic=69120.0
500 2012-03-18 20:38:19 <devrandom> BlueMatt: what is bitcoin-deps?
501 2012-03-18 20:39:04 <BlueMatt> luke-jr: pulled all the deps other than qt and boost into one zip
502 2012-03-18 20:39:14 <BlueMatt> its gitian-descriptors/deps-win32.yml
503 2012-03-18 20:39:19 <BlueMatt> but I think its only required for win32
504 2012-03-18 20:40:37 <devrandom> BlueMatt: I have to go, will look at it tonight
505 2012-03-18 20:40:48 <BlueMatt> alright, see ya
506 2012-03-18 20:45:37 <DBordello> Within the last couple of days my 0.60rc2 (and rc4) windows QT clients freeze at startup.  The GUI immediately becomes unresponse.  I don't see anything unusual in debug.log.  Any thoughts?
507 2012-03-18 20:46:56 <ageis> 0.5.3 corrupted my wallet, glad i had a backup
508 2012-03-18 20:48:54 <BlueMatt> ageis: more info?
509 2012-03-18 20:49:19 <BlueMatt> DBordello: you dont happen to be able to compile with DEBUG_LOCKORDER, do you?
510 2012-03-18 20:49:31 <DBordello> BlueMatt, I did not.  I grab the binary from a thread post
511 2012-03-18 20:49:39 <BlueMatt> which thread?
512 2012-03-18 20:49:57 <DBordello> Gavin
513 2012-03-18 20:50:06 <DBordello> It was from source forge
514 2012-03-18 20:50:10 <BlueMatt> mmm, yea
515 2012-03-18 20:50:33 <BlueMatt> but you're not set up to compile?
516 2012-03-18 20:50:48 <sipa> ageis: define "corrupted my wallet"
517 2012-03-18 20:50:56 <DBordello> BlueMatt, that is correct, not on windows anyways
518 2012-03-18 20:50:56 <sipa> ageis: which version did you use before?
519 2012-03-18 20:51:06 <ageis> sipa: 0.5.2
520 2012-03-18 20:51:17 <ageis> sipa: error message saying that
521 2012-03-18 20:51:19 <DBordello> it is obviously just the GUI freezing.  If I leave it running (unresponsive), but send coins, the next time I start it, the balance is updated
522 2012-03-18 20:51:45 <sipa> DBordello: which OS?
523 2012-03-18 20:51:55 <DBordello> sipa, Windows 7 x64
524 2012-03-18 20:52:02 <DBordello> Also, debug.log continues to update
525 2012-03-18 20:52:14 <sipa> and rc4 still has that problem?
526 2012-03-18 20:52:44 <DBordello> yes
527 2012-03-18 20:52:55 <DBordello> Bitcoin version 0.6.0.4-beta
528 2012-03-18 20:53:20 <DBordello> My hunch is that it is the "warning" that is being displayed, since that is the only thing that changed recently
529 2012-03-18 20:54:39 <DBordello> I just started with a clean data dir: http://imgur.com/Yg4KH
530 2012-03-18 20:54:41 <DBordello> after reezing
531 2012-03-18 21:02:03 <deoxxa> how should i go about setting up a service that accepts bitcoin as payment? i'm relatively competent with programming (see https://github.com/deoxxa/) so i'm not afraid of putting something together myself, but i'm guessing there's a pretty standard way of going about it.
532 2012-03-18 21:04:17 <DBordello> Anythoughts on how to debug my "freezing" windows client?
533 2012-03-18 21:09:15 <freewil> deoxxa, if you want to use node, there is a bitcoin module
534 2012-03-18 21:09:26 <freewil> deoxxa, https://github.com/jb55/node-bitcoin
535 2012-03-18 21:10:47 <deoxxa> node is good
536 2012-03-18 21:11:24 <deoxxa> how do i go about actually accepting payments, though?
537 2012-03-18 21:11:40 <deoxxa> hm, "go about" must be my subconscious phrase of the day
538 2012-03-18 21:11:57 <freewil> deoxxa, you will want to create a unique address that you can use to link to a single transaction
539 2012-03-18 21:12:07 <freewil> you can use the getnewaddress api call
540 2012-03-18 21:12:21 <deoxxa> ah i see
541 2012-03-18 21:12:41 <deoxxa> so i give the customer that address, then as soon as it hits a certain balance they get their product?
542 2012-03-18 21:13:00 <deoxxa> that makes sense
543 2012-03-18 21:13:07 <word> well, depending on what the product is
544 2012-03-18 21:13:10 <freewil> deoxxa, right, but you want to wait until the transaction gets to a minimum confirmation number to prevent double-spending attacks
545 2012-03-18 21:13:13 <word> you might want to wait for confirms
546 2012-03-18 21:13:20 <freewil> which is usually 6
547 2012-03-18 21:13:42 <deoxxa> it'd probably be something like a subscription service
548 2012-03-18 21:13:46 <word> if it's a service like giving them access to something, as long as they can't hurt it, you could give access right away and just cut them off if the confirms don't pan out
549 2012-03-18 21:13:49 <deoxxa> no physical goods
550 2012-03-18 21:13:50 <deoxxa> yeah
551 2012-03-18 21:13:53 <deoxxa> that's what i'm thinking
552 2012-03-18 21:14:14 <deoxxa> how long does the first notification take generally?
553 2012-03-18 21:14:18 <word> but you'll want the process to be automated so you don't have to audit loads
554 2012-03-18 21:14:39 <word> first notification?
555 2012-03-18 21:14:49 <deoxxa> well, first confirmation thing
556 2012-03-18 21:15:09 <deoxxa> how long after them sending sweet, sweet BC do i first find out?
557 2012-03-18 21:15:11 <word> well blocks happen around every 10 minutes
558 2012-03-18 21:15:23 <deoxxa> ah cool
559 2012-03-18 21:15:27 <word> but i think you get notified of transactions sooner
560 2012-03-18 21:15:31 <sipa> the transaction should appear almost instantly (seconds)
561 2012-03-18 21:15:32 <freewil> you should receive the transaction almost instantly with 0 confirms
562 2012-03-18 21:15:34 <deoxxa> oh even better
563 2012-03-18 21:15:42 <deoxxa> that works well then
564 2012-03-18 21:15:44 <sipa> but for various reasons, that can fail
565 2012-03-18 21:15:56 <sipa> you will certainly get it at its first confirmation
566 2012-03-18 21:16:07 <sipa> which should be within the hour but often sooner
567 2012-03-18 21:16:20 <sipa> after that, one extra confirmation per on average 10 minutes
568 2012-03-18 21:16:26 <sipa> until infinity
569 2012-03-18 21:17:25 <word> idk if this will work right for a subscription service, but opencart has an extension to use bitpay so it'd just be another payment method
570 2012-03-18 21:18:02 <word> the point being, look around before you start writing code to make sure you don't reinvent the wheel. :)
571 2012-03-18 21:19:44 <luke-jr> devrandom: http involves admin overhead
572 2012-03-18 21:20:24 <sipa> ;;bc,blocks
573 2012-03-18 21:20:25 <gribble> 171786
574 2012-03-18 21:22:32 <deoxxa> how do i test bitcoin transactions?
575 2012-03-18 21:23:12 <word> test?
576 2012-03-18 21:23:53 <Graet> send bitcoins to me :)
577 2012-03-18 21:24:11 <Graet> i'll confirm for you that it works :)
578 2012-03-18 21:24:12 <luke-jr> deoxxa: -tesntet
579 2012-03-18 21:24:15 <luke-jr> -testnet *
580 2012-03-18 21:24:23 <deoxxa> well, testing this not-quite-a-thing web service
581 2012-03-18 21:24:44 <Graet> ahh ok
582 2012-03-18 21:24:56 <dwon> So I just read BIP 30: "Blocks are not allowed to contain a transaction whose identifier matches that of an earlier, not-fully-spent transaction in the same chain. "
583 2012-03-18 21:25:22 <dwon> Why not just say that blocks are not allowed to have the same coinbase as a previous block?  Then you wouldn't impose additional storage requirements.
584 2012-03-18 21:26:13 <dwon> are there duplicate coinbases in the block chain already?
585 2012-03-18 21:26:15 <sipa> dwon: it would require keeping all coinbases forever
586 2012-03-18 21:26:28 <sipa> dwon: which is reasonable, but unnecessary
587 2012-03-18 21:26:49 <luke-jr> sipa: well, to be fair, it *could* have specified "coinbases only"
588 2012-03-18 21:27:04 <sipa> luke-jr: no need for a special case
589 2012-03-18 21:27:08 <dwon> sipa: I think it's more likely that more unspent transactions will hang around than coinbases.
590 2012-03-18 21:27:31 <dwon> actually I could *make* a bunch of low-value unspent transactions right now, forcing everyone to keep these around forever.
591 2012-03-18 21:27:33 <sipa> this way it also protect against derived transactions from existing duplicate coinbases with 0 effort
592 2012-03-18 21:27:38 <dwon> at least, if it was coinbases, I'd need hashing power
593 2012-03-18 21:28:17 <sipa> dwon: sure, but the priority here was a solution that was easy to implement, so that it would be uncontroversial and a fast upgrade was possible
594 2012-03-18 21:28:22 <sipa> i believe that succeeded
595 2012-03-18 21:29:04 <luke-jr> sipa: it's impossible to make derived txns from existing dupes
596 2012-03-18 21:29:33 <sipa> how so?
597 2012-03-18 21:29:42 <sipa> (are they all spent?)
598 2012-03-18 21:29:49 <dwon> sipa: I don't really buy that excuse.  The TLS renegotiation vulnerability was far worse than this, and the solution still wasn't rushed.
599 2012-03-18 21:31:59 <sipa> dwon: so, your argument is that disallowing duplicate coinbases would also solve the problem? sure, but BIP30 is easier to implement and protects against more
600 2012-03-18 21:33:05 <dwon> my argument is that coinbases can't be created at arbitrary rates by an attacker, unlike unspent transactions
601 2012-03-18 21:33:11 <gmaxwell> Attn Windows Bitcoin GUI users: There is a potential security hole fixed by 0.5.3.1 / 0.6.0rc4. PLEASE UPGRADE. https://bitcointalk.org/index.php?topic=69120.0
602 2012-03-18 21:33:31 <luke-jr> sipa: because once the txn is replaced by a dupe, it can't be used as an input
603 2012-03-18 21:33:31 <sipa> dwon: yes, i never argued with that, but why does that matter?
604 2012-03-18 21:34:25 <sipa> luke-jr: it could be, and then rolled back; but that would require a rollback to a point before the dupe was mined, which is indeed for all practical purposes impossible
605 2012-03-18 21:34:32 <sipa> so yes, that is not a very strong argument
606 2012-03-18 21:34:39 <sipa> still, i prefer the simplicity of the patch
607 2012-03-18 21:36:06 <dwon> ... "the simplicity of the patch".  The thing that disturbs me the most is that a lot of people in here seem to think of the Satoshi bitcoind and the bitcoin protocol as the same thing.
608 2012-03-18 21:36:33 <sipa> it is currently the only fully-validating client i know of
609 2012-03-18 21:36:54 <sipa> and this is a change that only affects fully validating clients
610 2012-03-18 21:37:50 <sipa> by the way, there is another proposal as well, to include the block height in the coinbase, as a protocol rule; implicitly guaranteeing uniqueness
611 2012-03-18 21:38:18 <sipa> but that would be harder to roll out quickly, as people use coinbases for various things already
612 2012-03-18 21:38:32 <dwon> sipa: That really would be the best thing.  Is it likely to happen?
613 2012-03-18 21:38:37 <sipa> yes
614 2012-03-18 21:38:41 <sipa> but not immediately
615 2012-03-18 21:38:48 <dwon> Ah, okay, so BIP 30 could become a moot point when it does.
616 2012-03-18 21:39:14 <sipa> indeed
617 2012-03-18 21:39:30 <dwon> ok, I'm done whining, then. :)
618 2012-03-18 21:55:22 <gribble> New news from bitcoinrss: sipa opened pull request 948 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/948>
619 2012-03-18 22:00:30 <gribble> New news from bitcoinrss: laanwj opened pull request 949 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/949>
620 2012-03-18 22:33:11 <gmaxwell> Attn Windows Bitcoin GUI users: There is a potential security hole fixed by 0.5.3.1 / 0.6.0rc4. PLEASE UPGRADE. https://bitcointalk.org/index.php?topic=69120.0
621 2012-03-18 22:54:29 <etotheipi_> sipa, gmaxwell, did the wallet encryption change in 0.6.0?  i.e. I wrote a tool for decrypting and extracting keys that seems to work 0.5.X wallets, but not 0.6
622 2012-03-18 22:55:40 <sipa> etotheipi_: maybe it is not compatible with compressed pubkeys?
623 2012-03-18 22:58:39 <etotheipi_> hmmm
624 2012-03-18 22:58:42 <etotheipi_> that's a very good point
625 2012-03-18 23:01:44 <etotheipi_> sipa, so when you decrypt a key, it previously used the hash of the 65-byte public key to decrypt.  Is it now using the hash of the 33 byte public key?
626 2012-03-18 23:02:04 <etotheipi_> err.. hash of public key for IV
627 2012-03-18 23:09:47 <sipa> etotheipi_: yes
628 2012-03-18 23:09:55 <sipa> but that shouldn't be a problem
629 2012-03-18 23:10:39 <sipa> the only problem i can think of is that when verifying the integrity, if the public key is 33 bytes, you should compare it against the compressed form of the public key corresponding to the private key you just decrypted
630 2012-03-18 23:10:41 <etotheipi_> sipa, it's not a problem, I just want to make sure I get it right
631 2012-03-18 23:11:15 <etotheipi_> my code fails because it verifies the private key against the public key:  which is incomprehendable to Armory right now
632 2012-03-18 23:14:17 <BlueMatt> oh, oops, I think https://github.com/bitcoin/bitcoin/issues/933 blocks 0.6 as well
633 2012-03-18 23:22:01 <sipa> BlueMatt: indeed
634 2012-03-18 23:22:28 <BlueMatt> sipa: wanna mark it as such?
635 2012-03-18 23:22:43 <BlueMatt> (github really should let people mark stuff...)
636 2012-03-18 23:22:53 <luke-jr> ^
637 2012-03-18 23:23:04 <luke-jr> at least stuff like Bug/Feature/etc
638 2012-03-18 23:23:17 <BlueMatt> actually, github should replace their bugtracking system with a real bugtracking system...
639 2012-03-18 23:23:29 <luke-jr> ofc, I'd much prefer someone write a better competitor to GitHub
640 2012-03-18 23:23:36 <sipa> BlueMatt: how about i fix it, instead?
641 2012-03-18 23:23:42 <BlueMatt> that works too
642 2012-03-18 23:23:52 <luke-jr> BlueMatt: I'd be willing to host a Bugzilla on bugs.bitgit.org if people wanted one
643 2012-03-18 23:23:57 <luke-jr> or some other sane bug tracker
644 2012-03-18 23:24:05 <BlueMatt> luke-jr: only if it can import from github...
645 2012-03-18 23:24:08 <BlueMatt> which is the issue
646 2012-03-18 23:24:15 <luke-jr> BlueMatt: ah, that might not be as simple
647 2012-03-18 23:24:36 <luke-jr> otoh, I can't imagine it'd be hard to script; happen to know if GitHub ToS allow it?
648 2012-03-18 23:24:45 <BlueMatt> nfc, Id assume so
649 2012-03-18 23:24:51 <BlueMatt> if they have an api, Id assume so
650 2012-03-18 23:25:12 <deoxxa> could probably ask them nicely for an export
651 2012-03-18 23:25:57 <luke-jr> who wants to research the best  bugtracker? :p
652 2012-03-18 23:26:12 <deoxxa> depends on what you want it to do
653 2012-03-18 23:26:20 <BlueMatt> Id say track bugs
654 2012-03-18 23:26:34 <deoxxa> good news: github has that built in
655 2012-03-18 23:26:42 <deoxxa> now, what do you *really* want it to do
656 2012-03-18 23:26:56 <BlueMatt> have sane tagging mechanisms
657 2012-03-18 23:27:00 <BlueMatt> ie tag categories
658 2012-03-18 23:27:10 <BlueMatt> sane milestones
659 2012-03-18 23:27:22 <BlueMatt> bug assignment
660 2012-03-18 23:27:43 <BlueMatt> everything you would expect a bug tracker to have
661 2012-03-18 23:28:47 <freewil> sounds like github issues
662 2012-03-18 23:28:57 <BlueMatt> what in that list can github do?
663 2012-03-18 23:29:00 <Diablo-D3> git flow > *.
664 2012-03-18 23:29:04 <BlueMatt> have sane tagging mechanisms - no
665 2012-03-18 23:29:07 <Diablo-D3> blueMatt: oh, all of those
666 2012-03-18 23:29:11 <BlueMatt> milestones - no
667 2012-03-18 23:29:13 <freewil> yes
668 2012-03-18 23:29:14 <BlueMatt> bug assignment - no
669 2012-03-18 23:29:16 <freewil> it has all those
670 2012-03-18 23:29:20 <Diablo-D3> I can write closes #bugnumber and github automatically closes those
671 2012-03-18 23:29:31 <BlueMatt> no, it just links to the issue
672 2012-03-18 23:29:32 <Diablo-D3> I can assign and tag bugs in the bug tracker
673 2012-03-18 23:29:36 <Diablo-D3> bluematt: nope
674 2012-03-18 23:29:40 <Diablo-D3> it actually closes it
675 2012-03-18 23:29:44 <sipa> it closes it
676 2012-03-18 23:29:46 <BlueMatt> Diablo-D3: no, you can give it a label that says "Diablo"
677 2012-03-18 23:29:52 <BlueMatt> that isnt assignment
678 2012-03-18 23:29:57 <Diablo-D3> no, you can assign
679 2012-03-18 23:30:01 <BlueMatt> where?
680 2012-03-18 23:30:18 <sipa> BlueMatt: with push rights, you can
681 2012-03-18 23:30:25 <BlueMatt> thats worthless though...
682 2012-03-18 23:30:27 <Diablo-D3> bluematt: Im looking at, say, this
683 2012-03-18 23:30:31 <Diablo-D3> https://github.com/Diablo-D3/DiabloMiner/issues/39
684 2012-03-18 23:30:41 <Diablo-D3> I see a "No one is assigned [gear box drop down]"
685 2012-03-18 23:30:47 <Diablo-D3> I click the gear
686 2012-03-18 23:30:56 <Diablo-D3> it pops up a pop up that allows me to assign
687 2012-03-18 23:30:58 <BlueMatt> ok, so its worthless unless you can give everyone push rights
688 2012-03-18 23:31:01 <BlueMatt> which is stupid
689 2012-03-18 23:31:06 <Diablo-D3> huh?
690 2012-03-18 23:31:07 <freewil> BlueMatt, https://github.com/blog/831-issues-2-0-the-next-generation
691 2012-03-18 23:31:12 <Diablo-D3> outsiders should NEVER assign bugs
692 2012-03-18 23:31:22 <Diablo-D3> if you dont have push rights, you're not a member of the project.
693 2012-03-18 23:31:34 <BlueMatt> not at all true
694 2012-03-18 23:31:38 <BlueMatt> see: bitcoin
695 2012-03-18 23:31:45 <Diablo-D3> yes, and bitcoin has basically one dev.
696 2012-03-18 23:31:46 <Diablo-D3> gavin.
697 2012-03-18 23:31:49 <BlueMatt> ???
698 2012-03-18 23:31:52 <Diablo-D3> the rest of you are just frequent committers
699 2012-03-18 23:31:54 <BlueMatt> what are you smoking?
700 2012-03-18 23:32:00 <BlueMatt> yea, but what if I want to fix a bug
701 2012-03-18 23:32:08 <BlueMatt> am I not allowed to say "Ive got this one"?
702 2012-03-18 23:32:22 <Diablo-D3> then fix it and in the commit log "closes #xxxxx"
703 2012-03-18 23:32:28 <Diablo-D3> when gavin merges it, it'll close.
704 2012-03-18 23:32:40 <BlueMatt> not unless Im a commiter, I think
705 2012-03-18 23:32:48 <Diablo-D3> nope, it'll import the close.
706 2012-03-18 23:32:51 <BlueMatt> because I know ive committed bugs that say closes #xxx and it didnt close
707 2012-03-18 23:33:06 <Diablo-D3> Ive seen bugs that did it.
708 2012-03-18 23:33:06 <freewil> BlueMatt, even if you arent a member of the project, the issue page will have a reference to your commit in your own repo
709 2012-03-18 23:33:11 <gmaxwell> Attn Windows Bitcoin GUI users: There is a potential security hole fixed by 0.5.3.1 / 0.6.0rc4. PLEASE UPGRADE. https://bitcointalk.org/index.php?topic=69120.0
710 2012-03-18 23:33:22 <BlueMatt> freewil: that is != closing the bug