1 2012-11-20 01:45:36 <jgarzik> BlueMatt: was it you talking about a bitcoin meetup somewhere in RDU area?
  2 2012-11-20 01:45:45 <jgarzik> past or future
  3 2012-11-20 01:48:21 <Luke-Jr> 
ACTION is meeting up with gmaxwell, forrestv, and amiller tomorrow in Orlando <.<

  4 2012-11-20 03:16:54 <Luke-Jr> whee, successfully running a "sub-pool" under Eligius or BitMinter using GBT :D
  5 2012-11-20 03:28:32 <theymos> I was using an old version of bitcoind (~0.6) on blockexplorer.com, and it looks like someone exploited a DoS attack: The disk was nearly filled up with blkxxxx.dat files. Probably fixed in the newer Bitcoin versions, but I thought it was interesting.
  6 2012-11-20 03:53:02 <Luke-Jr> theymos: 0.6.4?
  7 2012-11-20 03:53:27 <theymos> Probably not. One of the earlier versions of 0.6, I think.
  8 2012-11-20 04:01:35 <theymos> I think I was using code I grabbed from git at commit dd199d0. I saved the blkxxx files if anyone wants to look at them.
  9 2012-11-20 04:02:05 <Luke-Jr> theymos: can I get the first 1 MB of the last one?
 10 2012-11-20 04:02:29 <theymos> OK, just a minute.
 11 2012-11-20 04:04:01 <Luke-Jr> theymos: actually, make it 3 MB just in case
 12 2012-11-20 04:07:26 <theymos> Luke-Jr: https://blockexplorer.com/d/dosLast
 13 2012-11-20 04:07:47 <theymos> (Just noticed that I misnamed it: it's really the front.)
 14 2012-11-20 04:08:49 <theymos> 14 blkxxxx files were created. Then it seems bitcoind couldn't really handle any more and it became too slow to do anything.
 15 2012-11-20 04:19:34 <Luke-Jr> theymos: this is interesting, they look like valid blocks
 16 2012-11-20 04:19:52 <Luke-Jr> theymos: any chance you could setup a SSH account with read-only access to them so we don't need to transfer the whole files?
 17 2012-11-20 04:20:25 <theymos> Sure.
 18 2012-11-20 04:26:50 <theymos> Luke-Jr: Sent you a msg.
 19 2012-11-20 04:27:13 <Luke-Jr> theymos: ok thanks
 20 2012-11-20 04:27:43 <Luke-Jr> not sure I'll get to it tonight, but maybe we can connect it at the meetup tomorrow and take a look as a group or something
 21 2012-11-20 04:27:44 <Luke-Jr> not sure I'll get to it tonight, but maybe we can connect it at the meetup tomorrow and take a look as a group or something
 22 2012-11-20 04:28:28 <theymos> OK. I'm also going to sleep soon.
 23 2012-11-20 06:17:59 <Godzilla123_> Hi another qn about transactions :P
 24 2012-11-20 06:18:22 <Godzilla123_> A received x bitcoins from X and y from Y.
 25 2012-11-20 06:18:29 <Godzilla123_> A wants to send x+y bitcoins to B
 26 2012-11-20 06:18:51 <Godzilla123_> so tx will reference the old tx from X and Y
 27 2012-11-20 06:19:05 <Godzilla123_> and it will say give (x+y) bitcoins to B
 28 2012-11-20 06:19:21 <Godzilla123_> what will A sign here
 29 2012-11-20 06:19:31 <Godzilla123_> how man signatures will this tx from A to B contain
 30 2012-11-20 06:21:15 <Godzilla123_> how many signatures will this tx from A to B contain
 31 2012-11-20 06:24:52 <midnightmagic> A signs the output tx to B. it'll require one signature on that output.
 32 2012-11-20 06:25:18 <midnightmagic> you can check yourself by building the raw tx and decoding it afterwards..
 33 2012-11-20 07:07:48 <jgarzik> ;;bc,halfreward
 34 2012-11-20 07:07:53 <gribble> Error: invalid syntax (<string>, line 1)
 35 2012-11-20 07:07:54 <gribble> Error: invalid syntax (<string>, line 1)
 36 2012-11-20 07:09:37 <jgarzik> ;;bc,halfreward
 37 2012-11-20 07:09:38 <gribble> Estimated time of bitcoin block reward halving: Sun Sep  1 19:39:00 2013 | Time remaining: 40 weeks, 5 days, 18 hours, 30 minutes, and 0 seconds
 38 2012-11-20 07:10:11 <jgarzik> nanotube: gribble is bonkers :)
 39 2012-11-20 07:10:34 <bonks> 
ACTION gribble

 40 2012-11-20 07:41:58 <Godzilla123_> midnightmagic: How do I do that? can you please send me a reference
 41 2012-11-20 07:42:23 <Godzilla123_> midnightmagic: here is another way to put my question (hopefully this is more clear)
 42 2012-11-20 07:43:14 <Godzilla123_> I make a tx (A<--X, A<--Y) --> B
 43 2012-11-20 07:43:34 <Godzilla123_> so I must sign (A <-- X) under A and (A <-- Y) under B
 44 2012-11-20 07:43:37 <Godzilla123_> so I must sign (A <-- X) under A and (A <-- Y) under A
 45 2012-11-20 07:43:38 <Godzilla123_> so I must sign (A <-- X) under A and (A <-- Y) under A
 46 2012-11-20 07:44:15 <Godzilla123_> What about the entire tx (A<--X, A<--Y) --> B .... it also needs a signature from A.. so there must be three signatures
 47 2012-11-20 07:44:37 <sipa> only the inputs contain signatures
 48 2012-11-20 07:44:38 <sipa> only the inputs contain signatures
 49 2012-11-20 07:44:52 <Godzilla123_> then anyone can replace the output by his own output
 50 2012-11-20 07:45:20 <Godzilla123_> how is the input linked to output in an irremovable way?
 51 2012-11-20 07:46:23 <xenland> whats X and Y?
 52 2012-11-20 07:46:24 <xenland> whats X and Y?
 53 2012-11-20 07:46:47 <xenland> 
ACTION scrolled up

 54 2012-11-20 07:46:48 <xenland> 
ACTION scrolled up

 55 2012-11-20 07:47:01 <Godzilla123_> X and Y are previous tx outputs that send coins to A
 56 2012-11-20 07:47:09 <Godzilla123_> A is the input for the current tx
 57 2012-11-20 07:47:16 <Godzilla123_> and B is the output for the current tx
 58 2012-11-20 07:47:17 <Godzilla123_> and B is the output for the current tx
 59 2012-11-20 07:47:38 <xenland> Are X and Y go into the same address or seperte?
 60 2012-11-20 07:47:45 <xenland> separate*
 61 2012-11-20 07:47:53 <Godzilla123_> same
 62 2012-11-20 07:48:08 <Godzilla123_> X and Y are earlier transactions with A as output
 63 2012-11-20 07:49:01 <xenland> Sounds like you just need one signature if your sending from one address(not to be confused with wallet)
 64 2012-11-20 07:49:02 <xenland> Sounds like you just need one signature if your sending from one address(not to be confused with wallet)
 65 2012-11-20 07:49:13 <xenland> As far as i understand
 66 2012-11-20 07:49:24 <Godzilla123_> "Transactions are cryptographically signed records that reassign ownership of Bitcoins to new addresses. "
 67 2012-11-20 07:49:28 <Godzilla123_> from the wiki
 68 2012-11-20 07:49:32 <xenland> yep
 69 2012-11-20 07:49:49 <Godzilla123_> so either way, when an input sends funds to an output the (Input, output) pair needs to be signed
 70 2012-11-20 07:49:50 <Godzilla123_> so either way, when an input sends funds to an output the (Input, output) pair needs to be signed
 71 2012-11-20 07:50:07 <Godzilla123_> otherwise anyone can replace the output with some other output before forwarding the request
 72 2012-11-20 07:51:00 <xenland> As far as i understand you are correct
 73 2012-11-20 07:51:14 <sipa> Godzilla123_: it's still the entirevtransaction being signed
 74 2012-11-20 07:51:28 <sipa> but there is one signature for each input
 75 2012-11-20 07:52:00 <sipa> so you can't change any part of the transaction without invalidating it
 76 2012-11-20 07:52:29 <xenland> I think you just need two signatures to combine the Bitcoins into another address after that you just need one to send it out.
 77 2012-11-20 07:52:40 <xenland> need one signature to send it out*
 78 2012-11-20 07:53:34 <xenland> (The input/output terminology confuses me with out using the word Bitcoin address)
 79 2012-11-20 07:53:42 <xenland> (Sorry for not sounding more properly on that area)
 80 2012-11-20 07:53:53 <xenland> proper*
 81 2012-11-20 07:53:54 <xenland> proper*
 82 2012-11-20 07:54:26 <sipa> xenland: get used to it, because internally bitcoin doesn't use addresses
 83 2012-11-20 07:54:27 <sipa> xenland: get used to it, because internally bitcoin doesn't use addresses
 84 2012-11-20 07:54:41 <sipa> that's just the authentication layer on top
 85 2012-11-20 07:54:42 <xenland> sipa: good to know :)
 86 2012-11-20 07:54:59 <sipa> transactions produce outputs, and consume outputs
 87 2012-11-20 07:55:00 <sipa> transactions produce outputs, and consume outputs
 88 2012-11-20 07:55:08 <xenland> Thats the confusing part
 89 2012-11-20 07:55:23 <xenland> people using input output but its just one thing, not exactly seperate in my minds eye
 90 2012-11-20 07:55:39 <xenland> Did you find your self having to hurddle over something like this?
 91 2012-11-20 07:55:46 <sipa> an output creates a coin, an input consumes a coin
 92 2012-11-20 07:55:52 <xenland> ah
 93 2012-11-20 07:56:01 <sipa> yes, it took me a few months to understand that
 94 2012-11-20 07:56:02 <sipa> yes, it took me a few months to understand that
 95 2012-11-20 07:56:26 <xenland> good to know
 96 2012-11-20 07:56:27 <xenland> good to know
 97 2012-11-20 07:56:38 <xenland> outputs also mean "transferring coins" too right? or is that different way too?
 98 2012-11-20 07:57:01 <sipa> an output is an amount+an address
 99 2012-11-20 07:57:10 <sipa> so it gets "assigned" to someone
100 2012-11-20 07:57:11 <sipa> so it gets "assigned" to someone
101 2012-11-20 07:57:30 <xenland> okay, that helps a lot acutally
102 2012-11-20 07:57:31 <xenland> okay, that helps a lot acutally
103 2012-11-20 07:57:36 <xenland> interesting
104 2012-11-20 07:58:05 <sipa> an input is the hash of the tx whose output is being consumed, the outout# of it being consumed, the public key corresponding to the address of the previous output, and a signature to prove it
105 2012-11-20 07:58:15 <sipa> in the common case
106 2012-11-20 07:58:54 <sipa> so inputs consume coins by proving ownership, recombine them, split them, and potentially reassign them
107 2012-11-20 07:59:56 <xenland> gotcha
108 2012-11-20 08:00:06 <xenland> 
ACTION writes down some more notes....

109 2012-11-20 08:01:28 <Godzilla123_> for each input, I need one signature that unlocks the funds from the prev output
110 2012-11-20 08:01:52 <Godzilla123_> because the verification crieteia may be different, so there should be one signature each
111 2012-11-20 08:02:59 <Godzilla123_> but now when I combine the funds into a bulk and send them to a bunch of outputs, how do I cryptographically link them? I need a signature again on the whole thing. So I think in the example we will need 3 signatures
112 2012-11-20 08:03:51 <Godzilla123_> otherwise things will be simpler if we just need one signature on the entire thing and not one for each input
113 2012-11-20 08:04:28 <Godzilla123_> so the wiki is not very clear on this
114 2012-11-20 08:04:38 <Godzilla123_> and looking inside the protocol is too messy
115 2012-11-20 08:05:21 <xenland> I'm guessing you already checked the Raw transactions wiki page? https://en.bitcoin.it/wiki/Raw_Transactions#Input_selection_control
116 2012-11-20 08:06:04 <xenland> If no one has the answer, i guess whats left is to test it
117 2012-11-20 08:06:37 <Godzilla123_> no I have not.. let me check if I can figure it using the
118 2012-11-20 08:06:38 <sipa> Godzilla123_: the thing being signed is a hash of the (almost) entire transaction
119 2012-11-20 08:06:54 <sipa> but there is oje signature in every input
120 2012-11-20 08:06:55 <sipa> but there is oje signature in every input
121 2012-11-20 08:07:03 <Godzilla123_> ok.
122 2012-11-20 08:07:16 <Godzilla123_> and the entire transaction is signed by which key.. ?
123 2012-11-20 08:07:35 <sipa> the key required by the output being spent
124 2012-11-20 08:07:43 <sipa> which is different for eaxh input
125 2012-11-20 08:08:07 <Godzilla123_> so the entire tx will be signed by multiple keys?
126 2012-11-20 08:08:13 <sipa> yes
127 2012-11-20 08:08:31 <sipa> it's not the actual entire transaction
128 2012-11-20 08:08:32 <sipa> it's not the actual entire transaction
129 2012-11-20 08:08:44 <sipa> in particular, the signatures themselves are not signed
130 2012-11-20 08:08:48 <Godzilla123_> hmm so it will be signed for each key of the input.. if I am correct
131 2012-11-20 08:08:53 <sipa> as tgat would cause an infinite loop
132 2012-11-20 08:08:54 <sipa> as tgat would cause an infinite loop
133 2012-11-20 08:09:06 <sipa> correct
134 2012-11-20 08:09:13 <Godzilla123_> so the signature overhead is O(#inputs)
135 2012-11-20 08:09:21 <sipa> correct
136 2012-11-20 08:09:36 <Godzilla123_> ya of course, signatures themselves are not signed :)
137 2012-11-20 08:09:59 <sipa> it makes sense, but it comolicates everything a lot in oractice :)
138 2012-11-20 08:10:00 <sipa> it makes sense, but it comolicates everything a lot in oractice :)
139 2012-11-20 08:10:42 <Godzilla123_> can you confirm that for n inputs, there are 2n signatureS?
140 2012-11-20 08:10:52 <xenland> I think so yea
141 2012-11-20 08:11:00 <xenland> I believe that is in some wiki page i read or somthing
142 2012-11-20 08:11:01 <xenland> I believe that is in some wiki page i read or somthing
143 2012-11-20 08:11:16 <Godzilla123_> and all this is specified in some RFC or somewhere I guess :)
144 2012-11-20 08:11:55 <xenland> Theres alot of info on everything its just really scattered to know if your right or not thats why I'm writing notes, i'm trying to build a Pseudo-client
145 2012-11-20 08:12:20 <Godzilla123_> Im trying to write a paper on the security / anonymity of bitcoin
146 2012-11-20 08:12:29 <Godzilla123_> so I need to understand exactly what is signed etc
147 2012-11-20 08:12:30 <xenland> sipa would have to confirm what you said though about the n to n2 thing
148 2012-11-20 08:12:35 <Godzilla123_> but not want to get my hands dirty with code
149 2012-11-20 08:12:38 <Godzilla123_> or protocols
150 2012-11-20 08:12:47 <xenland> oh i think i have good link for you in that case
151 2012-11-20 08:12:53 <xenland> let me see if i bookmarked it
152 2012-11-20 08:13:04 <sipa> Godzilla123_: heh?
153 2012-11-20 08:13:09 <Godzilla123_> a signature linking some input-outputs for example reduces anonymity
154 2012-11-20 08:13:17 <sipa> why would there be two signatures for each input?
155 2012-11-20 08:13:18 <sipa> why would there be two signatures for each input?
156 2012-11-20 08:13:55 <xenland> hmmm true
157 2012-11-20 08:14:06 <Godzilla123_> sipa I think using this logic. Each input needs one signature to unlock it from previous output
158 2012-11-20 08:14:12 <Godzilla123_> so n signatures for n inputs
159 2012-11-20 08:14:15 <sipa> yes
160 2012-11-20 08:14:28 <sipa> that's all there is
161 2012-11-20 08:14:37 <xenland> Here is something that might help you visuialize but its alot of info at once: https://bitcointalk.org/index.php?topic=29416.0
162 2012-11-20 08:14:38 <xenland> Here is something that might help you visuialize but its alot of info at once: https://bitcointalk.org/index.php?topic=29416.0
163 2012-11-20 08:14:42 <Godzilla123_> and then the entire tx needs a signature.. but the question was under which public key does this signature verify
164 2012-11-20 08:14:44 <xenland> visualize*
165 2012-11-20 08:15:26 <sipa> Godzilla123_: for every input, there is one signature: the data being signed is the entire transaction itself, the key is the one demaned by the coin being soent
166 2012-11-20 08:15:41 <Godzilla123_> how do I link the outputs of the current tx with the inputs, so that no one else (e.g. the miner) replaces the actual output address with his address
167 2012-11-20 08:15:43 <sipa> this proves the previous owner of the coin approves of it being used in this transaction
168 2012-11-20 08:15:52 <Godzilla123_> checking link
169 2012-11-20 08:16:07 <sipa> because ifbyou change the transaction, all signatures become invalid!
170 2012-11-20 08:16:12 <xenland> Godzilla123, by signing your using the private key approriate to the public key (i think)
171 2012-11-20 08:16:13 <Godzilla123_> sipa: ah that is better
172 2012-11-20 08:16:13 <xenland> Godzilla123, by signing your using the private key approriate to the public key (i think)
173 2012-11-20 08:16:15 <sipa> the data being signed is the transaction
174 2012-11-20 08:16:16 <Godzilla123_> I think it clears
175 2012-11-20 08:16:21 <sipa> so changing that breaks
176 2012-11-20 08:16:31 <Godzilla123_> so each private key signs the entire transaction
177 2012-11-20 08:16:50 <xenland> Godzilla: yeah and its verifyiable by the public key (Bitcoin address)
178 2012-11-20 08:16:52 <Godzilla123_> that is what I was thinking. Why not do that :)
179 2012-11-20 08:16:55 <Godzilla123_> in the first place
180 2012-11-20 08:17:17 <xenland> (obviously im' still learning so listen to sipa first LOL)
181 2012-11-20 08:17:18 <xenland> (obviously im' still learning so listen to sipa first LOL)
182 2012-11-20 08:17:37 <Godzilla123_> sipa:  thanks for that
183 2012-11-20 08:17:45 <Godzilla123_> :)
184 2012-11-20 08:18:37 <Godzilla123_> I consider inputs and outputs as addresses
185 2012-11-20 08:18:45 <Godzilla123_> is there anything wrong in this assumption
186 2012-11-20 08:19:07 <xenland> As far as sipa explained earlyer to me if your a developer yes
187 2012-11-20 08:19:45 <Godzilla123_> input is actually a tuple (address, prev output ref)
188 2012-11-20 08:20:03 <Godzilla123_> output is simply address
189 2012-11-20 08:20:06 <xenland> If i had to guess, i'd say no, unless you had to escalate the details of the inter workings of Bitcoins for someone who is capable of understanding
190 2012-11-20 08:20:45 <xenland> I think the output only exists in pairs of an input
191 2012-11-20 08:20:48 <Godzilla123_> xenland: what language are you writing the client in
192 2012-11-20 08:20:53 <Godzilla123_> and what libraries are you using
193 2012-11-20 08:21:00 <xenland> In every language
194 2012-11-20 08:21:01 <xenland> In every language
195 2012-11-20 08:21:02 <xenland> but
196 2012-11-20 08:21:07 <xenland> the kicker is that its written in english
197 2012-11-20 08:21:09 <xenland> Pseudo-Code
198 2012-11-20 08:21:22 <xenland> so far I just have java and php to generate and verify addresses
199 2012-11-20 08:21:33 <xenland> and then the English explanations along with them
200 2012-11-20 08:21:35 <t7> im rubbish at playing mtgox
201 2012-11-20 08:22:00 <xenland> (and i think Inputs are attached by their signatures)
202 2012-11-20 08:22:15 <xenland> so basically an Bitcoin adddress is just proof of ownership in a sense with this logic
203 2012-11-20 08:22:16 <xenland> so basically an Bitcoin adddress is just proof of ownership in a sense with this logic
204 2012-11-20 08:22:27 <xenland> becuase your just signing the transactions away to another
205 2012-11-20 08:22:28 <xenland> becuase your just signing the transactions away to another
206 2012-11-20 08:22:33 <xenland> or proving you own those transactions
207 2012-11-20 08:22:53 <Godzilla123_> is there a #bitcoin-research
208 2012-11-20 08:23:09 <xenland> proof of transactions equals proof of currency and its verifyable
209 2012-11-20 08:23:36 <xenland> http://xenland.github.com/Bitcoin-Pseudocode-Client/
210 2012-11-20 08:23:41 <xenland> Some more material
211 2012-11-20 08:23:42 <xenland> Some more material
212 2012-11-20 08:23:59 <xenland> See a Bitcoin address created in action step by step http://xenland.github.com/Bitcoin-Pseudocode-Client/verifyaddress.html
213 2012-11-20 08:24:58 <xenland> I had someone help me with these pages too
214 2012-11-20 08:25:14 <t7> i started a micro crypto currency before just to help me realize how it worked
215 2012-11-20 08:25:14 <xenland> The information given on these pages are proveable by executing the code
216 2012-11-20 08:25:15 <Godzilla123_> proof of ownership is the signature
217 2012-11-20 08:25:17 <t7> it was fun
218 2012-11-20 08:26:17 <Godzilla123_> so the major overhead in a tx is the signatures if I am right
219 2012-11-20 08:26:37 <xenland> t7: I looked into hashcash I'm thinking of building my own simple currency with out all the high-grade security
220 2012-11-20 08:26:38 <xenland> t7: I looked into hashcash I'm thinking of building my own simple currency with out all the high-grade security
221 2012-11-20 08:26:46 <xenland> t7:Any source code left over?
222 2012-11-20 08:26:57 <robbak> Doesnt' mention that the last 8 chars are the first 8 of the hashed address.
223 2012-11-20 08:26:57 <xenland> Gozilla123_ what kind of overhead? storage size?
224 2012-11-20 08:27:08 <Godzilla123_> transmission and storage
225 2012-11-20 08:27:15 <Godzilla123_> each input needs one signature
226 2012-11-20 08:27:23 <t7> no it was really simple though, like 400 lines of haskell
227 2012-11-20 08:27:30 <xenland> robbak: i figured I'd leave that explaination to those who can see it and those who can't see it don't need to learn yet :P
228 2012-11-20 08:27:42 <Godzilla123_> sipa: can you please confirm that each input signs the same tx
229 2012-11-20 08:27:43 <t7> i should have made it a literate haskell file
230 2012-11-20 08:28:01 <t7> maybe i will do it again
231 2012-11-20 08:28:06 <Godzilla123_> and there are n signatures for n inputs
232 2012-11-20 08:28:06 <robbak> Godzilla123: Ok, Ok, :D
233 2012-11-20 08:28:22 <xenland> 
ACTION seraches haskell

234 2012-11-20 08:28:38 <xenland> oh that would be cool
235 2012-11-20 08:28:55 <xenland> That would be perfect for pseudo client project
236 2012-11-20 08:29:03 <xenland> A lazy programming language perfect
237 2012-11-20 08:29:04 <xenland> A lazy programming language perfect
238 2012-11-20 08:29:14 <Godzilla123_> xenland: tell me what exactly is a pseudo client :)
239 2012-11-20 08:30:31 <xenland> Godzilla123: To explain how the Bitcoin works, you run the bitcoin client in your mind. just how i would explain to a child why a volcano erupts I show the child visually and step by step and explain the chain reactions involved and pressure constraints cause the vineger and baking soda to pick the path of least resistance
240 2012-11-20 08:30:48 <xenland> But instead its with Bitcoin
241 2012-11-20 08:30:49 <xenland> But instead its with Bitcoin
242 2012-11-20 08:31:18 <Godzilla123_> cool
243 2012-11-20 08:31:25 <t7> xenland: the most awkward bit was having to implement my own elliptic curve crypto. But i found a really nice paper that walked me through it
244 2012-11-20 08:31:26 <t7> xenland: the most awkward bit was having to implement my own elliptic curve crypto. But i found a really nice paper that walked me through it
245 2012-11-20 08:31:42 <Godzilla123_> t7 can you please share that paper
246 2012-11-20 08:32:03 <t7> 2 secs
247 2012-11-20 08:32:04 <t7> 2 secs
248 2012-11-20 08:32:06 <Godzilla123_> or a link
249 2012-11-20 08:32:34 <xenland> t7: plz do! :) every time i hear the word curve itself i cringe!
250 2012-11-20 08:32:55 <xenland> let alone crypto and elliptic :P
251 2012-11-20 08:34:00 <t7> i printed it out but i have lost it :|
252 2012-11-20 08:34:31 <t7> http://hosteddocs.ittoolbox.com/AN1.5.07.pdf i think this was it
253 2012-11-20 08:34:32 <t7> http://hosteddocs.ittoolbox.com/AN1.5.07.pdf i think this was it
254 2012-11-20 08:35:22 <t7> the awkward bit for me was modular arithmetic. x / y (mod z)  is not the same as (x / y) % z
255 2012-11-20 08:35:32 <t7> i had to use egcd
256 2012-11-20 08:35:37 <t7> but you will work all this out :)
257 2012-11-20 08:36:52 <Godzilla123_> t7 unless y divides x
258 2012-11-20 08:36:58 <Godzilla123_> in which case it works :)
259 2012-11-20 08:37:19 <t7> i should have gone to university
260 2012-11-20 08:40:13 <Godzilla123_> that papers look good will check it out
261 2012-11-20 08:41:08 <xenland> Great find t7 thanks
262 2012-11-20 08:41:09 <xenland> Great find t7 thanks
263 2012-11-20 08:54:11 <Godzilla123_> what does "1 confirmation" mean?
264 2012-11-20 08:54:25 <Godzilla123_> does it mean that tx is part of a that has been mined
265 2012-11-20 08:54:38 <Godzilla123_> part of a block
266 2012-11-20 08:55:38 <Godzilla123_> nvm
267 2012-11-20 08:55:39 <Godzilla123_> Bitcoin confirmations represent the number of blocks in the block chain that have been accepted by the network since the block that includes the transaction.
268 2012-11-20 09:02:15 <Godzilla123_> its still not clear if the output addresses can be repeated. It makes sense for outputs to not be repeated
269 2012-11-20 09:02:16 <Godzilla123_> its still not clear if the output addresses can be repeated. It makes sense for outputs to not be repeated
270 2012-11-20 09:02:32 <Godzilla123_> becuase then when referring to a previous output, we can just refer to the tx id
271 2012-11-20 09:02:40 <Godzilla123_> otherwise, we have to refer to individual output
272 2012-11-20 09:03:03 <Godzilla123_> sipa: can you comment? :)
273 2012-11-20 09:06:15 <Godzilla123_> or we can refer to the index of the output.. not a big issue
274 2012-11-20 09:07:13 <Godzilla123_> xenland: that link you sent on bitcointalk is very useful
275 2012-11-20 09:08:35 <t7> Godzilla123 a transaction can have multiple inputs and outputs i believe. But you have to spend all the inputs
276 2012-11-20 09:09:11 <t7> so if i send you 1 BTC and i have 50 BTC, it will create 1 output to you and 1 output to me (49 come back to me)
277 2012-11-20 09:09:29 <t7> im not very good at explaining things ....
278 2012-11-20 09:09:44 <t7> i remember trying to teach my ex how to play poker
279 2012-11-20 09:11:15 <xenland> np godzilla123_
280 2012-11-20 09:11:57 <xenland> t7: that sounds right, and kinda explains why i keep seeing two input/outputs per transaction
281 2012-11-20 09:23:52 <Godzilla123_> t7 np that is a good explanation
282 2012-11-20 09:24:28 <Godzilla123_> essentially each output can be uniquely referenced by (tx ID, output index)
283 2012-11-20 09:24:42 <Godzilla123_> I was interested to know how the output is referenced
284 2012-11-20 09:25:00 <Godzilla123_> I didnt realize there was an index :)
285 2012-11-20 09:25:17 <Godzilla123_> so was worried how would be disambigute repeated outputs
286 2012-11-20 09:48:30 <t7> whats the time error allowance for a block?
287 2012-11-20 09:49:24 <t7> wiki says 2 hours ....
288 2012-11-20 09:53:40 <MC1984> is android still open source?
289 2012-11-20 09:53:49 <MC1984> or did they give up with that
290 2012-11-20 09:54:35 <robbak> NO, it's still 9open source. The curretn version of Andriod was released alonside the first 4.2 handsets.
291 2012-11-20 09:55:06 <robbak> Of course, tivoization of third party handsets is alive and well.
292 2012-11-20 09:59:02 <MC1984> what now
293 2012-11-20 09:59:41 <MC1984> can you compile your own android for your phone
294 2012-11-20 09:59:51 <MC1984> are there android distros you can install?
295 2012-11-20 09:59:52 <MC1984> are there android distros you can install?
296 2012-11-20 10:00:56 <robbak> Yes, the most well knows is cyanogen. The only problem is that many handsets have locked bootloaders, and check that firmware is signed by the manufacturer's private key.
297 2012-11-20 10:01:56 <MC1984> thats terrible
298 2012-11-20 10:02:32 <robbak> Not that there aren't ways around that.
299 2012-11-20 10:03:03 <MC1984> seems like everything locked down is the future of cmputing :/
300 2012-11-20 10:03:04 <MC1984> seems like everything locked down is the future of cmputing :/
301 2012-11-20 10:03:18 <MC1984> app stores are fuckin wildly popular
302 2012-11-20 10:04:05 <robbak> The list of phones that work with cyanogen, either using manufacturer approved methods or hacks, is fairly comprehensive.
303 2012-11-20 10:05:01 <MC1984> yeah but locked bootloaders and shit is still the official position of the future
304 2012-11-20 10:05:02 <MC1984> yeah but locked bootloaders and shit is still the official position of the future
305 2012-11-20 10:05:21 <robbak> You lock'em down, we jemmy them back open. Hey-ho, arround we go, happy hackers all.
306 2012-11-20 10:05:33 <MC1984> look at iphones, they seems to be getting harder and harder to jailbreak as the cat and mouse game goes on
307 2012-11-20 10:06:08 <MC1984> the PS3 only just got busted open and the xbox never really did
308 2012-11-20 10:06:25 <MC1984> i like hackers but i fear its a war they cant keep winning forever
309 2012-11-20 10:07:16 <MC1984> especially when whats at stake might be general computation
310 2012-11-20 10:07:31 <MC1984> pray to stallman :(
311 2012-11-20 10:34:57 <t7> will bitcoin clients ignore transaction with inputs that dont exist? or just hold them till they do?
312 2012-11-20 10:34:58 <t7> will bitcoin clients ignore transaction with inputs that dont exist? or just hold them till they do?
313 2012-11-20 11:07:21 <sipa> t7: that's called the orphan transaction pool
314 2012-11-20 11:07:44 <sipa> t7: they're kept in memory, and randomlynerased when the pool becomes too big
315 2012-11-20 11:08:02 <sipa> Godzilla123: each input signs the entire transaction yes
316 2012-11-20 11:08:45 <Godzilla123> sipa: rhanks
317 2012-11-20 11:08:58 <sipa> Godzilla123: but it's not the full transaction that is beig signed, there is some postprocessing (like removing signatures, and doing some replacements/erasing as well)
318 2012-11-20 11:09:22 <Godzilla123> sipa: ok where are the details about this
319 2012-11-20 11:09:31 <sipa> Godzilla123: source code
320 2012-11-20 11:09:32 <sipa> Godzilla123: source code
321 2012-11-20 11:09:47 <Godzilla123> satoshi's code?
322 2012-11-20 11:09:50 <sipa> yes
323 2012-11-20 11:09:53 <kjj_> also, signing the whole thing is just the default.  there are flags that allow signing reduced parts too
324 2012-11-20 11:09:55 <Godzilla123> ok
325 2012-11-20 11:10:09 <sipa> yes, satoshi thought a lot about this
326 2012-11-20 11:10:11 <t7> in b4 formally verified crypto currency
327 2012-11-20 11:10:12 <t7> in b4 formally verified crypto currency
328 2012-11-20 11:10:29 <sipa> and had probably use cases in mind we don't know about any more
329 2012-11-20 11:10:30 <Godzilla123> thats the only thing I have not checked yet
330 2012-11-20 11:10:30 <sipa> and had probably use cases in mind we don't know about any more
331 2012-11-20 11:10:38 <kjj_> and there is a wiki page that describes the pre-processing
332 2012-11-20 11:10:42 <sipa> well, there are reimplementations
333 2012-11-20 11:11:25 <sipa> kjj_: not detailed enough to implement it yourself fully i think
334 2012-11-20 11:11:45 <t7> scared of collisions from other peoples sigs/addresses ?
335 2012-11-20 11:12:59 <kjj_> https://en.bitcoin.it/wiki/OP_CHECKSIG
336 2012-11-20 11:13:01 <kjj_> there it is!
337 2012-11-20 11:13:02 <kjj_> there it is!
338 2012-11-20 11:13:02 <sipa> Godzilla123: check SignatureHash in script.cpp
339 2012-11-20 11:13:55 <Godzilla123> ok
340 2012-11-20 11:13:55 <kjj_> sipa: I don't know if it is enough to implement signing, but it sure helps get you started
341 2012-11-20 11:14:28 <Godzilla123> ok
342 2012-11-20 11:14:50 <sipa> oh, that is certainly more detailed than i remember it
343 2012-11-20 11:14:51 <sipa> oh, that is certainly more detailed than i remember it
344 2012-11-20 11:15:16 <kjj_> etotheipi wrote up a TON of stuff after he figured it out writing armory
345 2012-11-20 11:15:17 <kjj_> etotheipi wrote up a TON of stuff after he figured it out writing armory
346 2012-11-20 11:15:25 <Godzilla123> so current clients all reuse the same code?
347 2012-11-20 11:15:45 <t7> i hope not
348 2012-11-20 11:16:41 <sipa> no they all have their oen implementation for this
349 2012-11-20 11:16:42 <sipa> no they all have their oen implementation for this
350 2012-11-20 11:16:59 <Godzilla123> how would one go about making slight changes here and there in the protocol
351 2012-11-20 11:17:00 <kjj_> if you are just looking to create and sign your own transactions, that is fairly easy.  if you are looking to verify signatures from the stock client, that is harder because it has to cover all cases
352 2012-11-20 11:17:15 <Godzilla123> say I want to add another check that satoshi didnt think of or maybe add another feature
353 2012-11-20 11:17:28 <t7> Godzilla123: thats another protocol
354 2012-11-20 11:17:31 <sipa> bitcoinj, bitcoinjs, libbitcoin, bitsofproof, ... all have scriot implementations now
355 2012-11-20 11:17:45 <t7> you will not be compatible with the existing network, you will get out of sync
356 2012-11-20 11:17:49 <Godzilla123> so it will be a fork
357 2012-11-20 11:17:53 <sipa> Godzilla123: the rules are defined by the satoshi code, no way to change it without breakinh compatobility
358 2012-11-20 11:17:55 <kjj_> just edit the stock client if you just want to make tweaks.
359 2012-11-20 11:18:23 <Godzilla123> say I want to propose an enhancement that increases anonymity
360 2012-11-20 11:18:33 <Godzilla123> but will require slight tweaks in the way signatures are computed..
361 2012-11-20 11:18:34 <Godzilla123> but will require slight tweaks in the way signatures are computed..
362 2012-11-20 11:18:46 <kjj_> forget it
363 2012-11-20 11:18:47 <sipa> impossible without a hard fork
364 2012-11-20 11:18:48 <Godzilla123> we can say that from block X onwards, this logic is also allowed
365 2012-11-20 11:18:48 <sipa> impossible without a hard fork
366 2012-11-20 11:19:01 <sipa> if everyone upgrades, yes
367 2012-11-20 11:19:09 <kjj_> well, if your idea is good enough, maybe.  but basically, assume that it won't happen
368 2012-11-20 11:19:09 <sipa> but that is hard
369 2012-11-20 11:19:10 <sipa> but that is hard
370 2012-11-20 11:19:19 <Godzilla123> is it easy to change the signature scheme?
371 2012-11-20 11:19:33 <Godzilla123> and the verifying logic.. without changing anything else
372 2012-11-20 11:19:38 <sipa> as i said: that is a hard fork
373 2012-11-20 11:19:54 <sipa> and we won't do a hard fork without very good reason
374 2012-11-20 11:19:56 <Godzilla123> ok
375 2012-11-20 11:20:11 <Godzilla123> when was the last one
376 2012-11-20 11:20:12 <Godzilla123> when was the last one
377 2012-11-20 11:20:24 <sipa> there had not rver been one
378 2012-11-20 11:21:19 <kjj_> if you want to improve anonymity, set up a system that lets nodes automatically coordinate pooled spending
379 2012-11-20 11:22:00 <kjj_> but that's quite a bit more than a tweak
380 2012-11-20 11:22:07 <sipa> Godzilla123: there is an exception: if you change a rule that only makes things that were allowed invalid, and not the other way around, you don't need a hard fork
381 2012-11-20 11:22:26 <sipa> it suffices for >50% of mining power to upgrade for such rules
382 2012-11-20 11:22:27 <sipa> it suffices for >50% of mining power to upgrade for such rules
383 2012-11-20 11:24:29 <Godzilla123> cool.. most likely it will be that way
384 2012-11-20 11:24:59 <sipa> bip16, bip30 and bip34 are examples of such "soft forks"
385 2012-11-20 11:25:00 <sipa> bip16, bip30 and bip34 are examples of such "soft forks"
386 2012-11-20 11:33:51 <sturles> Do some sites have trouble with coins sent in a sendmany transaction?  I get messages from buyers claiming they haven't received their coins, while other people I sent to in the same transaction received theirs.  The recepients who have problems use some kind of web service/wallet, but nobody have told me which.  Any reason why this could happen?
387 2012-11-20 11:34:21 <sturles> Nobody who got their soins in a standard sendtoaddress transaction have complained.
388 2012-11-20 11:34:28 <sturles> *coins
389 2012-11-20 11:47:28 <kinlo> sturles: if you send coins with a regular send, some coins are sent back to your wallet
390 2012-11-20 11:47:50 <kinlo> sturles: in other words, there is no real difference between a transaction sent with sendmany or a 1 target send
391 2012-11-20 11:47:51 <kinlo> sturles: in other words, there is no real difference between a transaction sent with sendmany or a 1 target send
392 2012-11-20 11:48:14 <kinlo> sturles: the receipients will always have to be able to look trough all transaction outputs
393 2012-11-20 11:48:28 <kinlo> sturles: so there should not be any problem
394 2012-11-20 11:49:38 <sturles> There shouldn't, but if I send to more than one user of the same service, it is always a possibility that the service stops processing after the first known recipient in a transaction.
395 2012-11-20 11:49:51 <sturles> A stupid service that is.
396 2012-11-20 11:49:52 <sturles> A stupid service that is.
397 2012-11-20 11:50:16 <kinlo> well, I have no clue about such services
398 2012-11-20 11:50:17 <kinlo> well, I have no clue about such services
399 2012-11-20 11:50:37 <kinlo> and I've been using sendmany for over a year now, never had anyone complain about not receiving their funds
400 2012-11-20 11:50:38 <kinlo> and I've been using sendmany for over a year now, never had anyone complain about not receiving their funds
401 2012-11-20 11:50:55 <kinlo> the stock bitcoin client didn't do it correctly tough
402 2012-11-20 13:57:14 <BlueMatt> ;;later tell jgarzik yea, I had mentioned the idea of an RDU bitcoin meetup a long time ago...Id still do it though
403 2012-11-20 13:57:15 <gribble> The operation succeeded.
404 2012-11-20 14:14:56 <sipa> rdu?
405 2012-11-20 14:15:28 <sipa> raleigh durham airport apparently
406 2012-11-20 14:16:54 <BlueMatt> yea, this area of north carolina
407 2012-11-20 14:17:34 <sipa> i'm only familiar with the few places in the us i've been :)
408 2012-11-20 14:17:47 <BlueMatt> heh, fair enough
409 2012-11-20 14:18:03 <sipa> BlueMatt: saw my comments on the bloomfilter pullreq?
410 2012-11-20 14:18:13 <sipa> some are perhaps more for general discussion
411 2012-11-20 14:18:33 <BlueMatt> sipa: yea, I have a few hours travel time today and will hopefully be addressing those
412 2012-11-20 14:18:50 <BlueMatt> (in addition to working more on bitcoinj implementations)
413 2012-11-20 14:19:23 <sipa> yeah, i think it would be nice to demonstrate its functionality if both sides were implemented and working together
414 2012-11-20 14:19:43 <BlueMatt> yep
415 2012-11-20 14:20:03 <sipa> but i hope we can merge soon
416 2012-11-20 14:22:33 <BlueMatt> hopefully after thanksgiving this week I will have addressed all outstanding issues
417 2012-11-20 14:23:09 <sipa> well the filteradd without load issue maybe needs some discussion on the mailiglist rather than the pullreq
418 2012-11-20 14:23:34 <BlueMatt> agreed
419 2012-11-20 14:23:35 <BlueMatt> agreed
420 2012-11-20 14:26:01 <gavinandresen> I'm on the 'you must load first' side of that issue
421 2012-11-20 14:27:41 <sipa> BlueMatt: is porting cpartialtree to java easily doable?
422 2012-11-20 14:27:42 <sipa> BlueMatt: is porting cpartialtree to java easily doable?
423 2012-11-20 14:27:59 <sipa> cpartialmerkle or how did i call it
424 2012-11-20 14:28:22 <BlueMatt> sipa: yea, I did most of the verification stuff already (almost all copy/paste refactor)
425 2012-11-20 14:28:35 <BlueMatt> not that that is how it should be ported, but...meh it works
426 2012-11-20 14:28:44 <BlueMatt> gavinandresen: Im somewhat partial to that as well
427 2012-11-20 14:33:15 <sipa> BlueMatt: by the way, a potential vulnerability of the merkle structure in general: the server can always claim a smaller total number of transactions, and use internal merkle hashes as leaf txids
428 2012-11-20 14:33:58 <sipa> since you're trusting the server for not omitting matched stuff anyway, that's not really a problem
429 2012-11-20 14:34:39 <kjj_> talking about UTXO again, right?
430 2012-11-20 14:34:59 <sipa> but maybe when two server reply for the same filtered block, and the number of txs in the block differs, you need to trust the larger one
431 2012-11-20 14:35:08 <sipa> kjj_: no, filteree blocks
432 2012-11-20 14:36:06 <kjj_> ahh, ok.  I was going to say the block proper would need to include the transaction bodies, and the server would be unable to fake them
433 2012-11-20 14:39:33 <BlueMatt> sipa: true, probably never a bad idea to ask multiple nodes for filtered blocks
434 2012-11-20 14:39:55 <kjj_> just have the receiver treat each node in the tree as not-final until it either has subnodes or a transaction
435 2012-11-20 16:16:51 <helo> 
ACTION notes that the acronym for Atomic Bitcoin Exchange is ABE :D

436 2012-11-20 16:18:48 <helo> (which is great as they ensure an honest exchange occurs)
437 2012-11-20 16:27:50 <Godzilla123> In the bitcoin protocol, what else can we put as the verification condition?
438 2012-11-20 16:28:33 <Godzilla123> within the script
439 2012-11-20 16:30:19 <Godzilla123> The script for a typical Bitcoin transfer to destination Bitcoin address D simply encumbers future spending of the bitcoins with two things: the spender must provide a public key that, when hashed, yields destination address D embedded in the script, and a signature to show evidence of the private key corresponding to the public key just provided
440 2012-11-20 16:30:43 <Godzilla123> apart from the *typical Bitcoin transfer* what else can we do
441 2012-11-20 16:34:18 <kjj_> well...  really any script that evaulates true will work
442 2012-11-20 16:34:48 <kjj_> but most nodes won't relay them or include them in blocks that they are attempting to mine, so most people have to limit themselves to the standard set
443 2012-11-20 16:35:54 <kjj_> there are pubkey transactions, address transactions, multisig (multiple pubkey) transactions.  and P2SH versions of some or all of those
444 2012-11-20 16:41:14 <ThomasV> https://www.v.me/
445 2012-11-20 16:46:17 <Godzilla123> kjj_: ok
446 2012-11-20 16:55:20 <BlueMatt> https://www.chargeback.cc/
447 2012-11-20 18:12:08 <midnightmagic> doh.
448 2012-11-20 18:12:09 <midnightmagic> doh.
449 2012-11-20 18:12:15 <midnightmagic> 
ACTION clearly hasn't built a raw tx in a while.

450 2012-11-20 18:12:16 <midnightmagic> 
ACTION clearly hasn't built a raw tx in a while.

451 2012-11-20 18:15:38 <midnightmagic> why would one sign outputs, it would be more complicated to combine sigs on the output in the event num(in) != num(out)
452 2012-11-20 18:15:39 <midnightmagic> why would one sign outputs, it would be more complicated to combine sigs on the output in the event num(in) != num(out)
453 2012-11-20 18:15:53 <midnightmagic> thanks sipa.
454 2012-11-20 18:16:25 <kjj_> ?
455 2012-11-20 20:25:25 <wizkid057> why did this transaction need change? couldn't bitcoind have simply used a single output since there was a perfect amount of inputs? https://blockchain.info/tx-index/33428910/9698856fa2bcaf91316a29cd2c8adbf93debae8ffb92a91842c1dda63699ec37
456 2012-11-20 20:25:26 <wizkid057> why did this transaction need change? couldn't bitcoind have simply used a single output since there was a perfect amount of inputs? https://blockchain.info/tx-index/33428910/9698856fa2bcaf91316a29cd2c8adbf93debae8ffb92a91842c1dda63699ec37
457 2012-11-20 20:25:47 <wizkid057> (the 0.01 BTC was the change, obviously)
458 2012-11-20 20:27:42 <kjj_> meh.  the coin selector can be a bit funny at times
459 2012-11-20 20:28:35 <wizkid057> ie, broken? :P
460 2012-11-20 20:28:36 <wizkid057> ie, broken? :P
461 2012-11-20 20:28:47 <kjj_> no, just funny
462 2012-11-20 20:29:07 <kjj_> the problem it is working on is unsolvable (NP)
463 2012-11-20 20:29:08 <kjj_> the problem it is working on is unsolvable (NP)
464 2012-11-20 20:29:33 <wizkid057> making larger than needed transacions doesnt seem funny... seems wasteful
465 2012-11-20 20:29:35 <kjj_> so it uses an approximate solver, and sometimes the chosen solution isn't ideal.  but that isn't the same as broken
466 2012-11-20 20:29:36 <kjj_> so it uses an approximate solver, and sometimes the chosen solution isn't ideal.  but that isn't the same as broken
467 2012-11-20 20:30:10 <kjj_> if you have a better algorithm for picking coins to spend, we'd love to see your patch.
468 2012-11-20 20:30:11 <kjj_> if you have a better algorithm for picking coins to spend, we'd love to see your patch.
469 2012-11-20 20:30:30 <wizkid057> i just might do that... or at least add code for simple results like this
470 2012-11-20 20:30:50 <freewil> the default client might be made to always create a change output no matter what
471 2012-11-20 20:30:56 <wizkid057> seems trivial for it to test the inputs to see if any of them negate the change output
472 2012-11-20 20:31:03 <gmaxwell> It does not.
473 2012-11-20 20:31:28 <gmaxwell> wizkid057: IIRC it tries an exact match first. Do you even know who created that txn?
474 2012-11-20 20:31:35 <wizkid057> I did
475 2012-11-20 20:32:25 <wizkid057> admittedly, that client is out of date... "version" : 60103
476 2012-11-20 20:33:00 <gmaxwell> oh well there was an old odd behavior that did that in some cases.
477 2012-11-20 20:33:01 <gmaxwell> oh well there was an old odd behavior that did that in some cases.
478 2012-11-20 20:33:03 <kjj_> what will really bake your noodle is that you don't know if a fee is needed when you are picking coins
479 2012-11-20 20:33:04 <kjj_> what will really bake your noodle is that you don't know if a fee is needed when you are picking coins
480 2012-11-20 20:33:39 <wizkid057> gmaxwell: would it be more than trivial if I attempted to patch the client to do a double check to see if any input coin values matched the change value?
481 2012-11-20 20:33:45 <gmaxwell> Yea, that produces some "but it's wrong!" allegations that are just weirdness from the selection objective not being convex.
482 2012-11-20 20:33:57 <gmaxwell> wizkid057: you don't need to do that.
483 2012-11-20 20:34:06 <wizkid057> seems like i do
484 2012-11-20 20:34:21 <gmaxwell> wizkid057: seems like you need to run software which doesn't have old bugs.
485 2012-11-20 20:34:31 <wizkid057> hmm
486 2012-11-20 20:34:47 <kjj_> wizkid057: here's the real problem...  0.2+0.5+0.3 might need a fee, but 0.2+0.5+0.3+0.01 might not.  odd as that may seem to you, it really can happen
487 2012-11-20 20:34:58 <wizkid057> well, if that was corrected, then, my apologies ;)
488 2012-11-20 20:34:59 <wizkid057> well, if that was corrected, then, my apologies ;)
489 2012-11-20 20:35:24 <gmaxwell> kjj_: yea, though that doesn't look like the case here.
490 2012-11-20 20:35:25 <gmaxwell> kjj_: yea, though that doesn't look like the case here.
491 2012-11-20 20:35:48 <kjj_> gmaxwell: the question is whether the picker knows enough in advance to make that call or not
492 2012-11-20 20:35:49 <kjj_> gmaxwell: the question is whether the picker knows enough in advance to make that call or not
493 2012-11-20 20:36:11 <kjj_> pretty easy for us to say, 2.7 days later, that it looks funny.  much harder to do in real time
494 2012-11-20 20:36:12 <kjj_> pretty easy for us to say, 2.7 days later, that it looks funny.  much harder to do in real time
495 2012-11-20 20:37:10 <gmaxwell> Thats just the non-convexity. Bitcoin uses a relaxation over the fees and because the objective is non-linear that can't always give optimal results.
496 2012-11-20 20:37:10 <kjj_> I guess you could get your candidate set ready, save a copy, then see if the transaction will still work with an extra input removed or not, and fail back to the copy
497 2012-11-20 20:37:11 <kjj_> I guess you could get your candidate set ready, save a copy, then see if the transaction will still work with an extra input removed or not, and fail back to the copy
498 2012-11-20 20:38:34 <gmaxwell> wizkid057: See commit 831f59ce8b179bd3180a73499da9b1dc1d5ecaeb
499 2012-11-20 20:38:35 <gmaxwell> wizkid057: See commit 831f59ce8b179bd3180a73499da9b1dc1d5ecaeb
500 2012-11-20 20:40:27 <wizkid057> gmaxwell: nice, thanks :)
501 2012-11-20 20:40:28 <wizkid057> gmaxwell: nice, thanks :)
502 2012-11-20 20:40:39 <wizkid057> guess I should update eventually
503 2012-11-20 20:40:42 <wizkid057> lol
504 2012-11-20 20:40:51 <gmaxwell> 
ACTION DOS attacks wizkid057 

505 2012-11-20 20:40:52 <gmaxwell> 
ACTION DOS attacks wizkid057 

506 2012-11-20 20:41:16 <wizkid057> oh well
507 2012-11-20 20:41:17 <wizkid057> oh well
508 2012-11-20 22:17:45 <jgarzik> meh
509 2012-11-20 22:17:59 <jgarzik> parsing src/test/data/script*.json is annoying