1 2011-09-20 00:04:59 <freewil> ive got a question about using listtransactions and the from param
  2 2011-09-20 00:06:04 <freewil> ...from is basically an offset of the number of transactions to skip... so if a transaction only has 1 confirmation or even 0, is there potential for this transaction to disappear in a future call to listtransactions?
  3 2011-09-20 00:06:53 <freewil> ... and in that case wouldn't you need to decrement from to avoid missing a transaction?
  4 2011-09-20 00:08:24 <forrestv> freewil, no, they appear as "orphaned" then
  5 2011-09-20 00:09:21 <freewil> forrestv, the category would change from "receive" to "orphaned" ?
  6 2011-09-20 00:10:50 <forrestv> freewil, yes, iirc
  7 2011-09-20 00:11:51 <freewil> so once a bitcoin client sees a transaction, it's not ever deleted, but simply orphaned?
  8 2011-09-20 00:12:12 <luke-jr> depends on the client
  9 2011-09-20 00:12:22 <freewil> well bitcoind
 10 2011-09-20 00:45:26 <nhodges> lol
 11 2011-09-20 00:45:28 <nhodges> windows developers
 12 2011-09-20 00:45:29 <nhodges> :D
 13 2011-09-20 00:47:31 <gmaxwell> nhodges: it amazing that their keyboards don't all stop working from the accumuliated drool before they can get a post out.
 14 2011-09-20 00:48:13 <gmaxwell> "It's because I take it as a personal offense when people try to invade my time." < Ironic coming from the jackass who is making demands about other people package the source code to the software they've written
 15 2011-09-20 01:48:42 <midnightslipper> kittens, kittens, kittens.
 16 2011-09-20 02:27:34 <nhodges> what kind of hash is this
 17 2011-09-20 02:27:35 <nhodges> Vm9sdW1lMQ==
 18 2011-09-20 02:27:36 <nhodges> it represents Volume1
 19 2011-09-20 02:31:57 <forrestv> nhodges, not a hash; base64
 20 2011-09-20 03:03:16 <shadders> <shadders> two bitcoinds chattering to each other..
 21 2011-09-20 03:18:01 <theymos> New page on the wiki: https://en.bitcoin.it/wiki/Contingency_plans
 22 2011-09-20 03:18:30 <copumpkin> alert keys?
 23 2011-09-20 03:19:08 <neofutur> strange, Contingencyplan is also one of the aliases of foodstamp
 24 2011-09-20 03:26:26 <osmosis> neofutur, probably just because he has some kind of military background.
 25 2011-09-20 03:35:59 <nhodges> @theymos does alert mean embedding ascii into the blockchain a la len sassamman?
 26 2011-09-20 03:36:01 <nhodges> sassaman
 27 2011-09-20 03:36:06 <nhodges> on contingency plan
 28 2011-09-20 03:36:23 <theymos> No. It's a special message relayed between peers.
 29 2011-09-20 03:37:47 <nhodges> how would an end user of bitcoin alert you in the event of such an emergency
 30 2011-09-20 03:38:44 <theymos> Sending me an IM on AIM, XMPP, etc. would be the fastest way.
 31 2011-09-20 03:38:53 <theymos> You can also email me.
 32 2011-09-20 03:39:46 <Diablo-D3> heh its a theymos
 33 2011-09-20 03:41:55 <nhodges> for sure didn't realize it was an alert in a general sense, was thinking there was some proper avenue to send a bat signal, so to speak
 34 2011-09-20 03:43:41 <theymos> You should probably contact Gavin first, though. He's probably able to get an alert sent faster than me. The alert broadcaster code probably needs to be modified before it will run on modern versions, and I haven't done this yet.
 35 2011-09-20 03:44:00 <Diablo-D3> WHAT ALERT
 36 2011-09-20 03:44:30 <theymos> Bitcoin network alerts.
 37 2011-09-20 03:44:36 <Diablo-D3> ssince when
 38 2011-09-20 03:44:39 <nhodges> so there is a bat signal! lol
 39 2011-09-20 03:45:19 <theymos> Bitcoin's had an alert system since around 0.3.12, I believe.
 40 2011-09-20 03:45:34 <nhodges> oh okay, that's what i was kind of getting at, didn't know it was implemented
 41 2011-09-20 03:45:36 <nhodges> awesome
 42 2011-09-20 03:46:24 <theymos> The broadcaster code was written at around the same time, and it seems to rely on a GUI being present, so it probably needs to be modified before it will actually compile.
 43 2011-09-20 03:48:29 <JFK911> how do i use this
 44 2011-09-20 03:49:07 <JFK911> this should have been known previously
 45 2011-09-20 03:49:22 <JFK911> cosbycoin panic would have been more severe if bitcoin clients were popping these windows up also
 46 2011-09-20 03:52:09 <Blitzboom> hahahahaha
 47 2011-09-20 03:52:17 <Blitzboom> cosby issues a warning
 48 2011-09-20 03:56:28 <JFK911> that would be seriosuly freaky eh
 49 2011-09-20 03:58:30 <cronopio> yeah, seriously if the attacker want some profit, he should change all the BTC address in signatures for his own direcction
 50 2011-09-20 03:59:22 <JFK911> did he do that?
 51 2011-09-20 04:00:34 <Diablo-D3> COSBYCOIN
 52 2011-09-20 04:00:35 <Diablo-D3> I still cant buy those :<
 53 2011-09-20 04:00:42 <cronopio> JFK911: i think not, well i hope
 54 2011-09-20 04:05:26 <JFK911> oh well his javascript just changed pages after they were displayed
 55 2011-09-20 04:07:17 <cronopio> JFK911: yeah, he do that for show that Cosby message :P
 56 2011-09-20 04:37:35 <Disposition> huh
 57 2011-09-20 04:37:43 <Disposition> I make some food, btc price shoots up
 58 2011-09-20 04:38:04 <Disposition> I should cook more :P
 59 2011-09-20 04:40:17 <neofutur> Disposition: could be true . . . I also cooked today . . . rare thing
 60 2011-09-20 05:24:17 <theymos> New wiki article about alerts: https://en.bitcoin.it/wiki/Alerts
 61 2011-09-20 05:42:34 <nhodges> haha awesome theymos :D thanks
 62 2011-09-20 06:40:42 <midnightslipper> loltrolls
 63 2011-09-20 07:45:06 <neofutur> its just me or blockexplorer is lagging ?
 64 2011-09-20 07:47:34 <phantomcircuit> it's slow
 65 2011-09-20 07:53:42 <diki> there was a block explorer which had info on how many unique addresses there were in the block chain
 66 2011-09-20 07:53:46 <diki> anyone remember it?
 67 2011-09-20 07:56:10 <diki> i think the design of the site was blue-ish
 68 2011-09-20 08:47:42 <midnightslipper> aenima...
 69 2011-09-20 09:20:03 <d33tah> i tried to ask similar questions yesterday but seems like I was too sleepy...
 70 2011-09-20 09:20:15 <d33tah> how are bitcoin outputs created?
 71 2011-09-20 09:21:03 <d33tah> let's say we generate 50BTC and broadcast the block with all output sent to a user. what happens, from the mathematical point of view?
 72 2011-09-20 09:27:29 <sipa> nothing
 73 2011-09-20 09:27:44 <sipa> after that, the output exists within the chain the block is in
 74 2011-09-20 09:28:06 <d33tah> i mean, the value that the generator posesses is the signed header, right?
 75 2011-09-20 09:28:06 <sipa> and it can be redeemed by an input of a later transaction within the same chain
 76 2011-09-20 09:28:10 <sipa> no
 77 2011-09-20 09:28:22 <sipa> the generator has a private key
 78 2011-09-20 09:28:28 <sipa> and its corresponding public key
 79 2011-09-20 09:28:51 <d33tah> oh, just got an idea
 80 2011-09-20 09:28:56 <sipa> and the created output says "you need a signature with a public key X to spend me"
 81 2011-09-20 09:29:00 <d33tah> is it possible to generate 50BTC and send it into the void?
 82 2011-09-20 09:29:04 <d33tah> like, no outputs?
 83 2011-09-20 09:29:15 <sipa> no, because then you didn't create anything
 84 2011-09-20 09:29:22 <d33tah> i'd create an empty block
 85 2011-09-20 09:29:26 <d33tah> not possible?
 86 2011-09-20 09:29:37 <sipa> each transaction needs at least one ouput
 87 2011-09-20 09:29:41 <d33tah> ok
 88 2011-09-20 09:29:45 <sipa> and each block has at least a generation transaction
 89 2011-09-20 09:29:53 <d33tah> so, as you said
 90 2011-09-20 09:29:56 <d33tah> 13:28 < sipa> and the created output says "you need a signature with a public key X to spend me"
 91 2011-09-20 09:30:02 <d33tah> how is it expressed?
 92 2011-09-20 09:30:02 <sipa> yes
 93 2011-09-20 09:30:06 <sipa> in a script
 94 2011-09-20 09:30:38 <d33tah> in bitcoin, at the moment all scripts look all the same, except for the constants they provide, right?
 95 2011-09-20 09:30:47 <sipa> the OP_CHECKSIG operation takes two inputs: a public key, and a signature
 96 2011-09-20 09:30:58 <sipa> so the output is "<pubkey> OP_CHECKSIG"
 97 2011-09-20 09:31:06 <sipa> it assumes the signature is already on the stack
 98 2011-09-20 09:31:19 <d33tah> unencrypted public key of the address that previously had the output?
 99 2011-09-20 09:31:31 <sipa> no the pubkey of the address it is sent to
100 2011-09-20 09:31:37 <d33tah> okay
101 2011-09-20 09:31:41 <sipa> we're talking about outputs here
102 2011-09-20 09:31:51 <sipa> outputs define the conditions under which you can spend something
103 2011-09-20 09:31:54 <d33tah> i mean, i'd like to understand how the money is generated
104 2011-09-20 09:32:05 <sipa> inputs provide the proof for those conditions
105 2011-09-20 09:32:41 <d33tah> okay
106 2011-09-20 09:33:12 <sipa> money is created by collectively considering the longest blockchain authorative
107 2011-09-20 09:33:34 <sipa> under the rules defined by the bitcoin protocol
108 2011-09-20 09:33:38 <d33tah> ok, we create a block by successfully hashing it header
109 2011-09-20 09:33:51 <d33tah> the block points to its previous one, thus creating the longest blockchain
110 2011-09-20 09:33:55 <sipa> by hashing its header, and ending up with a number below the target
111 2011-09-20 09:34:02 <d33tah> right
112 2011-09-20 09:34:10 <d33tah> now, we are entitled to create outputs, right?
113 2011-09-20 09:34:10 <sipa> that is a 'proof of work'
114 2011-09-20 09:34:20 <sipa> no, you already created those
115 2011-09-20 09:34:37 <sipa> as the generation transaction is part of the block you just generated
116 2011-09-20 09:34:41 <sipa> and thus part of what you hashed
117 2011-09-20 09:34:47 <d33tah> ok
118 2011-09-20 09:34:57 <sipa> it is just "a valid block is allowed to contain one generation of up to 50 BTC"
119 2011-09-20 09:35:14 <sipa> and a generation is basically a transaction without outputs up to 50 BTC, but no inputs
120 2011-09-20 09:35:21 <d33tah> ok
121 2011-09-20 09:35:23 <sipa> eh with
122 2011-09-20 09:36:12 <d33tah> outputs up to 50BTC. let's say I want all the 50BTC to be sent to my address. i generate a txout. it contains its value and script, right?
123 2011-09-20 09:36:33 <sipa> yes, a txout is nothing more than an amount and a verification script
124 2011-09-20 09:37:01 <d33tah> and script contains the generator's public key and the output's signature?
125 2011-09-20 09:37:22 <sipa> the script is just "<pubkey> OP_CHECKSIG"
126 2011-09-20 09:37:46 <d33tah> oh, not generator's but receiver's i meant*
127 2011-09-20 09:37:56 <d33tah> so just the public key of the receiver and OP_CHECKSIG?
128 2011-09-20 09:37:56 <sipa> what receivers?
129 2011-09-20 09:38:01 <d33tah> of the output.
130 2011-09-20 09:38:01 <sipa> what are you talking about exactly?
131 2011-09-20 09:38:20 <sipa> the generation transaction, or something else?
132 2011-09-20 09:38:34 <d33tah> we generate 50BTC. we create an output to send it to somebody, then in its value we say it's 50BTC, and in it's script we just put the public key of the receiver and OP_CHECKSIG?
133 2011-09-20 09:39:10 <sipa> exactly
134 2011-09-20 09:39:25 <d33tah> okay
135 2011-09-20 09:39:33 <sipa> now, some time later
136 2011-09-20 09:39:38 <d33tah> hm?
137 2011-09-20 09:39:42 <sipa> you want to spend that output
138 2011-09-20 09:39:53 <sipa> eg, i want to send 20 BTC to you, and i have your address
139 2011-09-20 09:39:58 <sipa> ok?
140 2011-09-20 09:40:16 <d33tah> and you previously had this 50BTC?
141 2011-09-20 09:40:22 <sipa> yes
142 2011-09-20 09:40:25 <sipa> we're going to use that 50 BTC
143 2011-09-20 09:40:46 <d33tah> you use it as an input
144 2011-09-20 09:40:46 <sipa> assume the generation tx that gave us 50 BTC, is in a transaction whose hash is T
145 2011-09-20 09:41:01 <sipa> then you create a transaction T2
146 2011-09-20 09:41:16 <sipa> with as input T:0 (meaning output number #0 of transaction with hash T)
147 2011-09-20 09:41:23 <sipa> and two outputs
148 2011-09-20 09:41:57 <d33tah> 20 BTC to me, 30BTC change to you
149 2011-09-20 09:42:22 <sipa> the first output will give you 20 BTC, so it has value 20, and script "OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG"
150 2011-09-20 09:42:36 <d33tah> pubKeyHash being?
151 2011-09-20 09:42:41 <sipa> the address
152 2011-09-20 09:42:53 <d33tah> so, the 1blahblahblah?
153 2011-09-20 09:42:55 <sipa> remember, an address is just a base58 encoded hash of a public key
154 2011-09-20 09:42:57 <sipa> so you have that
155 2011-09-20 09:43:09 <sipa> but i skipped something
156 2011-09-20 09:43:16 <sipa> the input obviously also contains a script
157 2011-09-20 09:43:27 <d33tah> so the script is always the same and it just says that the money goes to a specific address?
158 2011-09-20 09:43:28 <sipa> the scriptSig (as opposed to outputs which have a scriptPubKey)
159 2011-09-20 09:43:34 <sipa> yes
160 2011-09-20 09:44:00 <sipa> the input's script simply contains <signature> if the corresponding pubKeyScript is "<pubkey> OP_CHECKSIG"
161 2011-09-20 09:44:18 <sipa> because that will make "<signature> <pubkey> OP_CHECKSIG" evaluate to true
162 2011-09-20 09:44:29 <d33tah> hm.
163 2011-09-20 09:44:44 <d33tah> pubkey = the key of the guy who received 50BTC
164 2011-09-20 09:44:51 <sipa> yes
165 2011-09-20 09:44:56 <d33tah> and the signature at this case?
166 2011-09-20 09:45:00 <d33tah> hold on, got a call
167 2011-09-20 09:45:15 <sipa> and <signature> is a signature of the transaction itself, using that same guy's private key
168 2011-09-20 09:45:44 <d33tah> and it's the first time we use somebody's private key.
169 2011-09-20 09:45:45 <sipa> therefore it is a proof that the owner of the key whose pubkeyhash is X, wanted to do that spend
170 2011-09-20 09:45:57 <sipa> yes, you use it to spend outputs
171 2011-09-20 09:46:05 <d33tah> by signing inputs
172 2011-09-20 09:46:10 <sipa> exactly
173 2011-09-20 09:48:20 <d33tah> afk sec
174 2011-09-20 09:51:25 <d33tah> what algorithm is used to sign inputs?
175 2011-09-20 09:51:50 <d33tah> i mean, create the <signature> part
176 2011-09-20 09:51:54 <sipa> ECDSA
177 2011-09-20 09:52:22 <d33tah> does it only have one variant?
178 2011-09-20 09:52:42 <d33tah> i mean, i can't find it in the openssl manpage
179 2011-09-20 09:53:22 <sipa> the openssl function is ECDSA_sign
180 2011-09-20 09:53:48 <d33tah> can I use openssl binary to test the encryption?
181 2011-09-20 09:54:00 <sipa> yes
182 2011-09-20 09:54:07 <d33tah> as I understand, all I need to sign a message is a message itself and my privkey, right?
183 2011-09-20 09:54:59 <sipa> yes
184 2011-09-20 09:55:20 <sipa> though getting either out of bitcoin is hard
185 2011-09-20 10:05:21 <d33tah> ok sipa
186 2011-09-20 10:05:39 <d33tah> so, the whole Bitcoin security lies in longest blockchain and signing inputs, right?
187 2011-09-20 10:06:05 <edcba> basically yes
188 2011-09-20 10:06:24 <d33tah> and having that data plus what is written on the wiki...
189 2011-09-20 10:07:04 <d33tah> to send a simple transaction, i'd need to know a) my privkey b) the amount c) the input's txid d) the destination public key?
190 2011-09-20 10:07:49 <d33tah> did I forget about anythin?
191 2011-09-20 10:07:56 <d33tah> anything*
192 2011-09-20 10:09:01 <sipa> you don't need d if you do a send-to-address
193 2011-09-20 10:09:10 <sipa> you need the hash of the public key instead
194 2011-09-20 10:09:30 <d33tah> so, the address.
195 2011-09-20 10:10:51 <sipa> you'll also need the prevout's #out
196 2011-09-20 10:10:59 <sipa> as in, a transaction can have multiple outputs
197 2011-09-20 10:11:08 <sipa> you need to know which number you want to spend
198 2011-09-20 10:11:26 <d33tah> is it an information that is signed?
199 2011-09-20 10:12:23 <d33tah> part of the signed input?
200 2011-09-20 10:13:29 <sipa> the entire transaction is signed
201 2011-09-20 10:13:36 <sipa> excluding the signatures themselves
202 2011-09-20 10:13:52 <d33tah> so, there is another algorithm used, aside from ECDSA?
203 2011-09-20 10:14:10 <d33tah> (that's where i'm starting to feel lost)
204 2011-09-20 10:14:45 <sipa> ?
205 2011-09-20 10:14:52 <GMP> ECDSA used for signing
206 2011-09-20 10:15:02 <sipa> the hashing of transaction and blocks is done using double SHA256
207 2011-09-20 10:15:19 <sipa> the hashing of pubkeys to address is done using SHA256+RIPEMD160
208 2011-09-20 10:15:24 <sipa> and signatures are made using ECDSA
209 2011-09-20 10:15:33 <d33tah> so, the transaction is just hashed, not signed?
210 2011-09-20 10:15:42 <d33tah> only the inputs are hashed?
211 2011-09-20 10:15:59 <sipa> transaction inputs contain a signature of the transaction they are contained within
212 2011-09-20 10:16:58 <d33tah> alright, so far I follow you
213 2011-09-20 10:17:34 <d33tah> what data exactly are signed? just the hash?
214 2011-09-20 10:18:10 <sipa> you take the entire transaction
215 2011-09-20 10:18:20 <sipa> you remove the signatures from it (because you don't know those)
216 2011-09-20 10:18:28 <sipa> you take the hash of the result
217 2011-09-20 10:18:36 <Diablo-D3> s/remove from/replace with 0
218 2011-09-20 10:18:45 <sipa> indeed
219 2011-09-20 10:18:47 <d33tah> signatures only, or whole the script?
220 2011-09-20 10:18:55 <sipa> signatures only, iirc
221 2011-09-20 10:19:02 <d33tah> okay
222 2011-09-20 10:19:08 <sipa> you give that hash, together with the private key to ECDSA_sign
223 2011-09-20 10:19:26 <sipa> an additional flag byte is added to the signature
224 2011-09-20 10:19:34 <sipa> and that is put in the transaction input script
225 2011-09-20 10:19:36 <Diablo-D3> d33tah: every single thing that self hashes (headers on internet traffic for example), you replace the hash field with 0 then hash
226 2011-09-20 10:19:48 <Diablo-D3> and then fix the field with the correctly computated hash
227 2011-09-20 10:19:59 <d33tah> okay
228 2011-09-20 10:20:29 <Diablo-D3> bitcoin is designed somewhat sanely according to varying standards of sane
229 2011-09-20 10:20:32 <d33tah> it sounds extremely complicated, but now that I'm concentrated, it seems understandable
230 2011-09-20 10:20:44 <Diablo-D3> its not complicated
231 2011-09-20 10:20:46 <Diablo-D3> most of the encryption use is blackboxed correctly
232 2011-09-20 10:20:59 <d33tah> could you do it with paper and pencil? :P
233 2011-09-20 10:21:07 <Diablo-D3> yes.
234 2011-09-20 10:21:27 <sipa> sha256 on paper would be horrible
235 2011-09-20 10:21:32 <sipa> and EC as well
236 2011-09-20 10:21:34 <sipa> but possible
237 2011-09-20 10:21:36 <Diablo-D3> EC yes
238 2011-09-20 10:21:43 <Diablo-D3> sha256 isnt so hard
239 2011-09-20 10:21:52 <Diablo-D3> just use an existing unrolled version
240 2011-09-20 10:21:56 <d33tah> the reason i'm asking you guys
241 2011-09-20 10:22:10 <d33tah> is i'm wondering what would I need to know to add bitcoin a bit of security
242 2011-09-20 10:22:15 <d33tah> with an external hashing chip
243 2011-09-20 10:22:27 <d33tah> i'm trying to strip the concept as much as possible
244 2011-09-20 10:22:27 <Diablo-D3> d33tah: you'd need to know none of it
245 2011-09-20 10:22:38 <d33tah> what I learnt atm is this:
246 2011-09-20 10:22:43 <Diablo-D3> in addition, dedicated encryption accelerators do nothing for the normal bitcoin process.
247 2011-09-20 10:23:04 <d33tah> 1) hack the bitcoin client to never store the private key on hdd, instead, save it on the external device, where it would be encrypted
248 2011-09-20 10:23:26 <sipa> why not just stored it encrypted on disk?
249 2011-09-20 10:23:46 <sipa> if you want the security of a trusted external device, you should make sure the key never leaves that device
250 2011-09-20 10:23:52 <d33tah> 2) when there is a transaction, the client asks the user to enter the password, then asks the device to sign the inputs with keys matching a specific address
251 2011-09-20 10:24:21 <sipa> which is what bitcoin 0.4 will, only with a wallet on disk
252 2011-09-20 10:24:24 <d33tah> 3) the device waits for physical confirmation (let's say a button pressed on it) to make sure it's not some trojan activity
253 2011-09-20 10:24:24 <sipa> *do
254 2011-09-20 10:24:50 <d33tah> then it retrieves the encrypted private key, signs the message it gets from the client and returns it signed
255 2011-09-20 10:25:31 <d33tah> if we did all on the PC, any keylogged could get the password and sign transactions on its own
256 2011-09-20 10:25:52 <sipa> yes, you're basically describing a bitcoin smartcard
257 2011-09-20 10:26:04 <d33tah> afaik, there is none on the market yet
258 2011-09-20 10:26:27 <sipa> uhu
259 2011-09-20 10:26:33 <d33tah> so
260 2011-09-20 10:26:42 <d33tah> i'd need to implement ECDSA on the smartcard
261 2011-09-20 10:26:46 <d33tah> and key storing, right?
262 2011-09-20 10:27:39 <sipa> yes
263 2011-09-20 10:27:55 <d33tah> which means i need to understand ECDSA
264 2011-09-20 10:28:01 <d33tah> assume I have 512 bytes EEPROM
265 2011-09-20 10:28:12 <d33tah> will that do, provided I only use a single address and don't encrypt it yet?
266 2011-09-20 10:28:46 <sipa> 512 bytes to store the ecdsa algorithm?
267 2011-09-20 10:28:50 <sipa> or to store the key?
268 2011-09-20 10:28:51 <d33tah> nah
269 2011-09-20 10:28:54 <sipa> the key is 32 bytes
270 2011-09-20 10:28:59 <d33tah> the algorithm should be in the flash
271 2011-09-20 10:29:04 <d33tah> key and address, i believe
272 2011-09-20 10:29:09 <d33tah> if it's all i need
273 2011-09-20 10:29:12 <sipa> you can calculate the address from the key
274 2011-09-20 10:29:26 <d33tah> do I even need it?
275 2011-09-20 10:29:29 <sipa> no
276 2011-09-20 10:29:32 <d33tah> okay
277 2011-09-20 10:29:36 <d33tah> so, 32 bytes
278 2011-09-20 10:29:42 <d33tah> makes it theoretically possible to store about 15 keys
279 2011-09-20 10:29:48 <sipa> well, you need to be able to ask your device what its address is, obviously
280 2011-09-20 10:30:19 <d33tah> the device just encrypts
281 2011-09-20 10:30:22 <d33tah> oh
282 2011-09-20 10:30:22 <sipa> no, it signs
283 2011-09-20 10:30:23 <sipa> it doesn't encrypt
284 2011-09-20 10:30:48 <d33tah> anyway
285 2011-09-20 10:30:52 <d33tah> i think i wouldn't need to
286 2011-09-20 10:30:56 <GMP> smartcard if headless device, how did sc know if its you who wants to sign something? what if cardreader device is compromised? smartcard will just sing transaction for the hacker
287 2011-09-20 10:31:14 <d33tah> if i stored the public key in the wallet.dat, i wouldn't need
288 2011-09-20 10:31:17 <d33tah> and GMP
289 2011-09-20 10:31:21 <d33tah> i think i'd make it this way:
290 2011-09-20 10:31:35 <d33tah> scenario 1: a user creates a transaction
291 2011-09-20 10:31:52 <sipa> imho smartphones are the way to go, not smartcards
292 2011-09-20 10:32:28 <d33tah> now, the transaction is sent, the password asked for, we enter it and the device encrypts ONLY AFTER the button is pressed
293 2011-09-20 10:32:41 <sipa> the device does not do encryptioj
294 2011-09-20 10:32:42 <sipa> n
295 2011-09-20 10:32:50 <d33tah> sorry, signing
296 2011-09-20 10:32:59 <d33tah> i guess it has to be annoying for you :p
297 2011-09-20 10:33:14 <d33tah> is there such a project for smartphones?
298 2011-09-20 10:33:35 <sipa> not sure
299 2011-09-20 10:33:42 <d33tah> anyway
300 2011-09-20 10:33:52 <d33tah> how do you imagine transferring the signature from smartphone to the PC?
301 2011-09-20 10:34:42 <sipa> not
302 2011-09-20 10:34:49 <d33tah> you mean, no idea?
303 2011-09-20 10:34:50 <sipa> there is no PC involved
304 2011-09-20 10:35:00 <d33tah> then it can be infected aswell
305 2011-09-20 10:35:23 <d33tah> it needs two devices to be relatively safe
306 2011-09-20 10:36:26 <d33tah> unless i got something wrong
307 2011-09-20 10:37:59 <someone42> d33tah: i've got some (pure) C code you might be interested in, ok to PM?
308 2011-09-20 10:38:09 <d33tah> someone42: sure
309 2011-09-20 10:39:07 <GMP> d33tah: i agree, some device + (not too smart) smartphone, and safe open communication between them
310 2011-09-20 10:39:32 <d33tah> meaning what? bluetooth?
311 2011-09-20 10:39:43 <d33tah> QRcodes? irda? usb? wifi?
312 2011-09-20 10:39:45 <sipa> NFC, wifi, QR code scanning, ...
313 2011-09-20 10:40:29 <GMP> 2-way QR is safest :)
314 2011-09-20 10:41:52 <d33tah> sipa: first time i hear of NFC
315 2011-09-20 10:43:58 <d33tah> btw
316 2011-09-20 10:44:05 <d33tah> mind checking out bitcoinbounties.org
317 2011-09-20 10:44:26 <d33tah> i once visited #bitcoin or #bitcoin-dev (can't remember) and found out you folks would like such service to exist
318 2011-09-20 10:45:25 <d33tah> i haven't heard a single comment of it yet
319 2011-09-20 10:45:56 <sipa> i'm not sure many people know of its existance
320 2011-09-20 10:47:14 <d33tah> i posted it on bitcointalk.org. got any further ideas?
321 2011-09-20 10:52:50 <GMP> what is the main reason that not just transaction is signed, but subscript of output of previous transaction as well? make verifing harder
322 2011-09-20 10:58:38 <mklarmann> hi :-) hi has anyone looked already at the implementation of the google wallet, if it is designed to potentially include bitcoins someday?
323 2011-09-20 10:59:43 <midnightslipper> puscifer, vaginas, etc.
324 2011-09-20 11:02:58 <MrSam> yes
325 2011-09-20 11:03:04 <MrSam> the whole world rotates around bitcoins
326 2011-09-20 11:03:11 <MrSam> i heard they are using cern as a miner
327 2011-09-20 11:03:34 <sipa> i assume it's designed to support mutliple currencies
328 2011-09-20 11:03:46 <MrSam> i'm not so sure
329 2011-09-20 11:03:54 <MrSam> i heard that they would introduce own currency
330 2011-09-20 11:04:05 <MrSam> but hidden, in a way like paypal does
331 2011-09-20 11:04:15 <MrSam> so exchange rate on every transaction
332 2011-09-20 11:29:05 <mklarmann> thank you for your opinions on this
333 2011-09-20 11:32:44 <jix> GMP: I don't know the details but I guess when address A transfers 1btc to address B... the owner of address B could just issue that transaction a 2nd time to steal 1btc from A
334 2011-09-20 11:35:06 <sipa> jix: no
335 2011-09-20 11:35:29 <sipa> after the transaction is included, its input coins do not exist anymore
336 2011-09-20 11:42:08 <jix> sipa: so a transaction clears all coins of the source address?
337 2011-09-20 11:42:50 <sipa> no
338 2011-09-20 11:43:03 <sipa> there doesn't exist something like "coins of an address"
339 2011-09-20 11:43:15 <sipa> there are "coins which an address' key gives access to"
340 2011-09-20 11:43:31 <sipa> but when spending coins, the transaction refers to the actual coins
341 2011-09-20 11:46:26 <jix> the scenario I had in mind was this: A: 10btc, B: 0btc; transactino of 1 btc from A -> B; A: 9btc, B: 1btc; now B just reissues the transaction; A 8btc; B: 2btc
342 2011-09-20 11:46:27 <jix> from what I understand it is possible to move only parts of the coins of an address... so unless a transaction signature also signs the preceding transaction from the source address it would be possible to just copy transactions
343 2011-09-20 11:47:13 <sipa> jix: forget what you know
344 2011-09-20 11:47:25 <sipa> there is nothing like moving coins from one address to another
345 2011-09-20 11:47:35 <sipa> there are just coins
346 2011-09-20 11:47:46 <MrSam> drugs !
347 2011-09-20 11:48:02 <sipa> and a transaction 1) consumes some specific coins 2) creates new coins of sizes whose sum doesn't exceed the consumed ones
348 2011-09-20 11:53:09 <imsaguy2> correction
349 2011-09-20 11:53:32 <imsaguy2> 2) creates new coins of sizes whose sum is equal to the consumed ones.
350 2011-09-20 11:53:36 <sipa> no
351 2011-09-20 11:53:42 <jix> imsaguy2: transaction fees?
352 2011-09-20 11:53:45 <sipa> the difference goes to fees
353 2011-09-20 11:53:48 <imsaguy2> yes, anything remaining is a transaction fee, but its still a coin
354 2011-09-20 11:53:53 <sipa> wrong
355 2011-09-20 11:54:00 <jix> but it's not created by the transaction
356 2011-09-20 11:54:04 <sipa> fees do not become a coin themselves
357 2011-09-20 11:54:18 <jix> they just increase the amount that can be mined
358 2011-09-20 11:54:23 <jix> don't they?
359 2011-09-20 11:54:25 <sipa> they are collected together in the block that mines them, and simple allows an increased generation
360 2011-09-20 11:54:57 <sipa> you can check the source code: the sum of the outputs of a tx <= the sum of the inputs of a tx
361 2011-09-20 11:55:18 <sipa> both can be zero, by the way
362 2011-09-20 11:55:29 <jix> sipa: I think I get it... but I'm not sure how this is handled: say I mined 50btc and then want to transfer 10btc of them... the transaction would then take all 50 of them forward 10btc to someone else and 40 back to me?
363 2011-09-20 11:55:39 <sipa> jix: exactly
364 2011-09-20 11:56:07 <jix> yeah that makes sense :) thanks
365 2011-09-20 12:20:27 <helo> is that done to reduce the number of important addresses?
366 2011-09-20 12:21:01 <sipa> no, that is done so a full node only needs to keep track of one thing: which txouts are spent?
367 2011-09-20 12:21:10 <sipa> instead of keeping full balances
368 2011-09-20 12:21:45 <sipa> plus, it allows more interesting things like txouts that are spendable by more than one address, or combinations thereof
369 2011-09-20 12:24:02 <helo> ic
370 2011-09-20 13:20:41 <CIA-101> libbitcoin: genjix * r0ad38146c223 /doc/readjust/ (readjust.png readjust.svg): Re-adjust documentation.
371 2011-09-20 13:43:14 <d33tah> hm
372 2011-09-20 13:43:29 <d33tah> is libbitcoin mainstream? supported by the official devs?
373 2011-09-20 13:53:54 <gavinandresen> libbitcoin is an independent project by "the bitcoin consultancy"
374 2011-09-20 13:58:11 <d33tah> why not merged?
375 2011-09-20 13:58:32 <d33tah> i mean, why doesn't a standard bitcoin client use a shared library?
376 2011-09-20 13:59:07 <sipa> it wasn't developed as such initially
377 2011-09-20 13:59:09 <gavinandresen> because writing good APIs is hard, and it hasn't been high on the priority list.
378 2011-09-20 13:59:16 <d33tah> ok
379 2011-09-20 13:59:22 <sipa> we're slowly moving towards more modularization, though
380 2011-09-20 14:00:08 <gavinandresen> the bitcoin consultancy folks are moving quickly, but also re-implementing from scratch, which is riskier.
381 2011-09-20 14:01:04 <ThomasV> will there be a separation between wallet and network daemon?
382 2011-09-20 14:02:56 <sipa> once both components are properly modularized, that shouldn't be hard to do
383 2011-09-20 14:03:56 <gavinandresen> yes, a completely hard and fast separation.  They won't be able to talk to each other at all, which will give maximum security, at the cost of a little inconvenience for the user (you won't be able to send or receive bitcoins).
384 2011-09-20 14:04:08 <sipa> lol gavinandresen
385 2011-09-20 14:04:56 <d33tah> ThomasV: seriously, what's the point?
386 2011-09-20 14:05:46 <ThomasV> gavinandresen: that was a real question
387 2011-09-20 14:05:52 <sipa> i'd like to see a system where you can run multiple nodes connected through a trusted network, and each node manages one or more wallets, or keeps a block chain database
388 2011-09-20 14:06:33 <gavinandresen> ThomasV: I know, I don't mean to pick on you.  There just seems to be some idea that having different processes manage the wallet and talk to the network will somehow protect the wallet more than having it all in one process.
389 2011-09-20 14:06:59 <sipa> it's the ideal of separation, which people seem to like
390 2011-09-20 14:07:03 <sipa> and rightfully so
391 2011-09-20 14:07:40 <sipa> but just having them both as well-defined modules that work more or less independently within the same process is as good, and a lot easier
392 2011-09-20 14:07:52 <ThomasV> well, I would love to be able to have my wallet on a smart card, or a separate device with screen+pincode
393 2011-09-20 14:08:10 <gavinandresen> ThomasV: that's a different feature from separation of network and wallet
394 2011-09-20 14:08:19 <ThomasV> why?
395 2011-09-20 14:08:40 <gavinandresen> ... because you need a wallet that knows how to talk to smart cards or separate devices
396 2011-09-20 14:09:03 <sipa> indeed, what you ask is in fact a separate wallet implementation that can be plugged into the framework
397 2011-09-20 14:09:17 <sipa> or at least a separate keystore, which is only part of the wallet
398 2011-09-20 14:09:19 <ThomasV> gavinandresen: I want ecdsa to be implemented in the smart card
399 2011-09-20 14:09:20 <gavinandresen> ... which is why I'd really like to come to consensus on multi-signature standard transactions soon....
400 2011-09-20 14:09:46 <sipa> gavinandresen: you mentioned it in the status-mail, but no follow-up mail followed
401 2011-09-20 14:10:23 <gavinandresen> sipa: I didn't want to start too many discussion threads at once
402 2011-09-20 14:10:31 <sipa> yeah, good thing probably
403 2011-09-20 14:10:54 <sipa> anyway, the very first step is agreeing on a subset of scripts that will be allowed to pass the IsStandard() test
404 2011-09-20 14:10:56 <gavinandresen> Proposal A is:   https://gist.github.com/39158239e36f6af69d6f
405 2011-09-20 14:11:07 <gavinandresen> Proposal B is:  https://gist.github.com/dba89537d352d591eb36
406 2011-09-20 14:11:07 <ThomasV> gavinandresen: I did read some of your mails about multi-sig, but I am not convinced ; it seems to be that (a or (b and c)) could be implemented at a different level, in the wallet encryption software
407 2011-09-20 14:11:36 <sipa> ThomasV: that at least requires one single wallet to hold the actual key
408 2011-09-20 14:12:01 <gavinandresen> ThomasV: what sipa said.  The goal is for private keys a,b,c to NEVER be on the same device at the same time
409 2011-09-20 14:12:39 <gavinandresen> (because if they are, a virus/trojan can hijack them)
410 2011-09-20 14:12:52 <ThomasV> but why is it necessary to put that in the bitcoin protocol?
411 2011-09-20 14:13:11 <sipa> it's the most elegant way imaginabl;e
412 2011-09-20 14:13:28 <gavinandresen> ThomasV: write up a Proposal C that does it outside the protocol and I'll be happy as a clam
413 2011-09-20 14:13:39 <sipa> the possibility for this kind of things is imho the one absolute advantage bitcoin has over any other currency
414 2011-09-20 14:14:41 <ThomasV> gavinandresen: sorry, I am not an expert, so I might be wrong about that. but it seems to me that adding new features to the protocol is not a priority, when the software itself needs to be perfected
415 2011-09-20 14:15:03 <sipa> the protocol doesn't need to be changed at all
416 2011-09-20 14:15:18 <ThomasV> oh, I thought it needed to
417 2011-09-20 14:15:21 <sipa> satoshi envisioned all these things in advance :)
418 2011-09-20 14:15:23 <gavinandresen> Yes, protocol is the same, set of transactions that are relayed/included in blocks is extended.
419 2011-09-20 14:15:45 <gavinandresen> And it is a priority because that has to be put in place BEFORE the feature actually gets exposed to users
420 2011-09-20 14:16:16 <gavinandresen> (otherwise users will be creating transactions that will never get into blocks)
421 2011-09-20 14:16:42 <gavinandresen> (well, not never... I think the Elgius pool would include them...)
422 2011-09-20 14:17:08 <ThomasV> well, if you say so... as I said, I am no expert on that question. my concern was about your general approach, adding features versus improving what exists
423 2011-09-20 14:17:31 <gavinandresen> ThomasV: what improvements do you want to see?
424 2011-09-20 14:18:05 <ThomasV> modularity, so that wallet and network can be two processes
425 2011-09-20 14:18:34 <d33tah> i'd personally love an improvement adding me like 1k BTC :d
426 2011-09-20 14:18:47 <sipa> modularity will come along the way
427 2011-09-20 14:18:50 <midnightmagic> sounds like the party lines of OpenBSD..
428 2011-09-20 14:18:55 <gavinandresen> mmm.  Not high on my priority list-- my priorities are network stability, and wallet backup/security.
429 2011-09-20 14:19:38 <ThomasV> gavinandresen: if these processes were separated, you could more easily involve people in them
430 2011-09-20 14:20:33 <sipa> you seem to confuse separation of the execution with separation of the logic
431 2011-09-20 14:21:01 <ThomasV> sipa: no, but if you do not have the latter, you cannot have the former
432 2011-09-20 14:21:07 <sipa> agree
433 2011-09-20 14:21:08 <midnightmagic> privilege separation, unprivileged setuid, and then you have to break two things and not just one.
434 2011-09-20 14:21:22 <midnightmagic> ah, The0.. wherefore art thou
435 2011-09-20 14:21:40 <gavinandresen> break the network code and you can send a message to the wallet that says "send all bitcoins here, please"
436 2011-09-20 14:22:05 <midnightmagic> unless the idea is the wallet is the origin of all sends.
437 2011-09-20 14:22:22 <gavinandresen> ... unless the wallet is locked, in which case the broken network code installs a keylogger and unlocks the wallet....
438 2011-09-20 14:22:43 <midnightmagic> unless the network code is an unprivileged user, in which case it must elevate its privileges
439 2011-09-20 14:22:51 <ThomasV> the network daemon should know nothing about keys. the wallet process should own the keys, and sign stuff
440 2011-09-20 14:23:44 <ThomasV> gavinandresen: security is easier on two small pieces of code than on a large one ; there are less interactions
441 2011-09-20 14:23:54 <midnightmagic> .. which would require 1) breaking the network daemon, and 2) breaking the system. not necessarily twice as hard, but certainly harder than just breaking the network daemon. this is partly the idea of qmail, and the central tenets of OpenBSD security auditing.
442 2011-09-20 14:25:15 <gavinandresen> midnightmagic ThomasV :  good points.
443 2011-09-20 14:25:23 <sipa> ThomasV: that's the key: limiting the interactions between wallet and main
444 2011-09-20 14:25:58 <midnightmagic> gavinandresen: just to be clear, I'm not advocating it, personally. I think you guys are doing a fine job. :) Offline wallets are a poor-man's version of this, and so I personally have no need of ThomasV's request. :)
445 2011-09-20 14:26:03 <gavinandresen> ... but the vulnerability I'm really interested in plugging isn't the "there's a buffer overflow in bitcoin", it is "your PC is a zombie"
446 2011-09-20 14:26:15 <midnightmagic> lol
447 2011-09-20 14:26:49 <gavinandresen> Because plugging the "your PC is a zombie" takes care of the buffer overflow problem, too
448 2011-09-20 14:27:30 <gavinandresen> afk for lunch for a while
449 2011-09-20 14:27:52 <midnightmagic> ciao gavin!
450 2011-09-20 14:28:56 <ThomasV> gavinandresen: if my wallet is implemented on a smart card, with its own keyboard and display, and it runs software that cannot be modified, then I will not have to care about the daemon running on a zombie PC
451 2011-09-20 14:29:27 <sipa> and you will also not care whether the wallet and the network code are separated
452 2011-09-20 14:29:41 <ThomasV> sipa: huh?
453 2011-09-20 14:29:42 <sipa> as long as the keystore functionality is moved to the smartcard
454 2011-09-20 14:30:04 <ThomasV> yes, that means separation, doesn't it ?
455 2011-09-20 14:30:21 <sipa> sure thing
456 2011-09-20 14:30:22 <sipa> but of a much smaller part of the code than you think
457 2011-09-20 14:30:40 <sipa> the wallet is a lot more than just keeping keys and storing them
458 2011-09-20 14:30:42 <ThomasV> how do you know what I think?
459 2011-09-20 14:31:02 <sipa> because you seem to think that the entire wallet should be a separate process
460 2011-09-20 14:31:16 <sipa> (which, i agree, would imply a very desirable degree of separation)
461 2011-09-20 14:31:57 <midnightmagic> software that cannot be modified could have an unfixable flaw.
462 2011-09-20 14:32:44 <ThomasV> midnightmagic: you do not fix the software in your smart cards, do you ?
463 2011-09-20 14:33:13 <ThomasV> you just buy a new card
464 2011-09-20 14:33:36 <midnightmagic> I hate smart cards. There's a reason why grey-market satellite flourished for so long.
465 2011-09-20 14:33:57 <midnightmagic> how do you get the old stuff on the old sc into the new one?
466 2011-09-20 14:34:11 <ThomasV> what stuff?
467 2011-09-20 14:34:21 <midnightmagic> you said you want the wallet on your smart card..?
468 2011-09-20 14:34:34 <ThomasV> keys? use a deterministic wallet
469 2011-09-20 14:34:46 <midnightmagic> that sounds scary
470 2011-09-20 14:34:55 <midnightmagic> "Now that is a big door!"
471 2011-09-20 14:35:00 <ThomasV> no, it's a or (b and c)
472 2011-09-20 14:35:16 <donpdonp> midnightmagic: "you want one? i make these cards"
473 2011-09-20 14:35:25 <midnightmagic> o
474 2011-09-20 14:35:26 <ThomasV> a is your passphrase, b and c are the card and the pin
475 2011-09-20 14:36:24 <midnightmagic> the problem with that is that you are trusting the aggregator with authority unless your SC is given authority to irrevocably sign a transaction to an independently-verifiable destination.
476 2011-09-20 14:36:38 <midnightmagic> i don't know of any smart cards with LCD displays.
477 2011-09-20 14:37:39 <ThomasV> no, you have cards that have memory that can be modified, plus some memory that is read only
478 2011-09-20 14:38:01 <ThomasV> and yes, there are cards with displays
479 2011-09-20 14:38:07 <BGL> new bot testing -> #bitcoin-cake
480 2011-09-20 14:38:09 <ThomasV> (not sure if lcd)
481 2011-09-20 14:43:46 <midnightmagic> but what i mean is, if the entire system but the smart card is compromised, then it can just ask the smartcard to sign a nefarious transaction to attacker Mallory, and unless you have some way of independently verifying the destination and signing just that destination, you've just given away your transaction volume to the wrong person.
482 2011-09-20 14:45:54 <ThomasV> midnightmagic: that is what the display on the card is for
483 2011-09-20 14:47:48 <mrb_> 09:36 < midnightmagic> i don't know of any smart cards with LCD displays.
484 2011-09-20 14:47:57 <mrb_> something even better exists: cards with e-paper displays
485 2011-09-20 14:48:11 <midnightmagic> mrb_: That's sexy.
486 2011-09-20 14:48:44 <ThomasV> yes, lcds are not bendable
487 2011-09-20 14:48:46 <mrb_> as thin and flexible as a credit card
488 2011-09-20 14:48:54 <mrb_> e-paper displays are flexible
489 2011-09-20 14:48:55 <midnightmagic> mrb_: Waterproof?
490 2011-09-20 14:49:02 <ThomasV> there's a taiwanese company that produces them
491 2011-09-20 14:49:11 <mrb_> eg. see the paypal security key (I have one)
492 2011-09-20 14:49:13 <midnightmagic> or rather..  laundry detergent+waterproof? :)
493 2011-09-20 14:49:14 <mrb_> https://www.paypal.com/us/cgi-bin/?&cmd=xpt/Marketing_CommandDriven/securitycenter/PayPalSecurityKey-outside
494 2011-09-20 14:49:15 <ThomasV> with pinpad and screen
495 2011-09-20 14:49:31 <midnightmagic> is that available to independent developers or is that one of those closed projects?
496 2011-09-20 14:49:32 <mrb_> midnightmagic: yes waterproof
497 2011-09-20 14:49:42 <mrb_> never put in the washer machine though :)
498 2011-09-20 14:49:55 <mrb_> I never put mine in the washer machine though :)
499 2011-09-20 14:50:07 <mrb_> there is no pinpad
500 2011-09-20 14:50:30 <cjdelisle> does it do wifi or something/
501 2011-09-20 14:50:31 <cjdelisle> ?
502 2011-09-20 14:50:53 <mrb_> manufacturers sell them to anyone, but for some strange reason, they are not very well known, despite their awesomeness
503 2011-09-20 14:51:26 <mrb_> it doesn't do wifi, there is a tamperproof chip that generates one-time pincodes
504 2011-09-20 14:51:31 <midnightmagic> hrm. that's odd. the last really awesome cards (in terms of technical construction) that I was exposed to were the directv smartcards.
505 2011-09-20 14:51:52 <mrb_> the built-in lithium-polymer battery is just as thin and flexible, and designed to last years
506 2011-09-20 14:52:07 <midnightmagic> lithium-polymer makes my jeans tight
507 2011-09-20 14:52:38 <cjdelisle> too bad they don't have a way to get the infoz from the computer about who wants your money
508 2011-09-20 14:53:07 <mrb_> I said no pinpad, but there could be one
509 2011-09-20 14:53:15 <mrb_> the paypal card has one input button
510 2011-09-20 14:53:43 <mrb_> I presume they could easily add a regular 3x4 pinpad
511 2011-09-20 14:53:53 <cjdelisle> mm 1 button would work as long as it could get input from the computer
512 2011-09-20 14:54:40 <mrb_> you could imagine a card that you program to send btc to 1 or 2 of your addresses
513 2011-09-20 14:54:52 <mrb_> you preload the card with many btc
514 2011-09-20 14:55:07 <mrb_> and use the pinpad occasionaly to withdraw btc to these preprogrammed addresses
515 2011-09-20 14:55:21 <cjdelisle> best IMO is: camera to snap qrcode, bitcoind node to keep track of balance and wifi to communicate with a POC device (to send the TX message)
516 2011-09-20 14:55:28 <mrb_> and the e-paper dispaly could be use to display a 2D barcode of the transaction
517 2011-09-20 14:55:40 <mrb_> that you scan with a smartphone
518 2011-09-20 14:55:53 <mrb_> yep.
519 2011-09-20 14:56:00 <cjdelisle> so that's more of a dedicated smartphone
520 2011-09-20 14:56:19 <midnightmagic> not if the txn was signed by the SC and couldn't be subverted by a naughty smartphone.
521 2011-09-20 14:56:30 <midnightmagic> in that case, either the txn gets through, or it doesn't.
522 2011-09-20 14:56:44 <mrb_> (in my example, the smartphone would be used to forward the txn, that's all, it wouldn't sign it or have access to the wallet)
523 2011-09-20 14:57:32 <cjdelisle> dedicated "secure" smartphone
524 2011-09-20 14:57:52 <midnightmagic> it would suck if I had to carry around 3 phones.
525 2011-09-20 15:06:54 <midnightmagic> great hostname, mosi, jesus
526 2011-09-20 15:07:32 <helo> hooge ftw
527 2011-09-20 15:08:18 <devrandom> gavinandresen: there?
528 2011-09-20 15:08:24 <gavinandresen> yes
529 2011-09-20 15:08:26 <midnightmagic> is that pronounced like hug but with a long u?
530 2011-09-20 15:09:26 <devrandom> gavinandresen: you do need 64 bit host to emulate a 64 bit guest
531 2011-09-20 15:09:37 <d33tah> is random seed needed to perform ECDSA_sign?
532 2011-09-20 15:09:55 <devrandom> I'm guessing your hw 64 bit and you installed 32 bit on it?
533 2011-09-20 15:10:27 <gavinandresen> devrandom: sigh.  Yup.  Is there an easy way to upgrade from 32 to 64 bit?  Or should I just wipe the disk and start again?
534 2011-09-20 15:11:59 <devrandom> I never tried upgrading 32->64.  It probably won't work while running from it, but maybe there's a way to upgrade from a live USB disk.
535 2011-09-20 15:12:34 <gavinandresen> devrandom: I already downloaded the 64-bit ISO because I figured the answer would be 'reinstall', I'll see what options it gives me.
536 2011-09-20 15:12:57 <gavinandresen> ... although actually, I didn't invest THAT much time into setup, so I might just wipe the disk anyway...
537 2011-09-20 15:13:25 <devrandom> yeah, probably faster
538 2011-09-20 15:13:53 <devrandom> glad that you are becoming gitian capable :)
539 2011-09-20 15:14:03 <gavinandresen> happy to be a guinea pig
540 2011-09-20 15:14:33 <devrandom> BlueMatt got a deterministic build for windows too
541 2011-09-20 15:14:45 <devrandom> (you probably are already aware)
542 2011-09-20 15:29:24 <d33tah> i'm reading openssl ECDSA code
543 2011-09-20 15:29:28 <d33tah> and i don't exactly understand
544 2011-09-20 15:29:36 <d33tah> what do i need random seed in key signing?
545 2011-09-20 15:49:15 <WakiMiko> quick question: why does the bitcoin client need to know its own external ip address?
546 2011-09-20 15:49:39 <Keefe> to advertise to others where it can be reached?
547 2011-09-20 15:50:47 <WakiMiko> so when a client is asked for addresses, it includes its own address? isnt that kinda redundant because the receiver is already connected to it anyway?
548 2011-09-20 15:52:17 <Keefe> i'm sure that's not where it's use
549 2011-09-20 15:52:19 <Keefe> used*
550 2011-09-20 15:53:02 <WakiMiko> hmm then where is it used?
551 2011-09-20 15:53:06 <Keefe> i haven't studied bitcoin's networking code
552 2011-09-20 15:53:18 <Keefe> just thinking it's similar to other p2p networks
553 2011-09-20 15:59:36 <jix> d33tah: for DSA (and that includes ECDSA) you need a random value that isn't predictable otherwise it's trivial to derive the private key from 2 signatures and the public key
554 2011-09-20 16:00:05 <jix> d33tah: see sony's ps3 fail
555 2011-09-20 16:38:32 <Disposition> huh, scene on wall street is actually pretty messy
556 2011-09-20 16:38:33 <Disposition> http://www.livestream.com/globalrevolution
557 2011-09-20 16:47:06 <CIA-101> bitcoin: Jeff Garzik master * r700f942 / src/net.cpp :
558 2011-09-20 17:07:52 <melvster1> i just installed the latest client on ubuntu ( sudo apt-add-repository ppa:stretch/bitcoin ) ... does anyone know if mining is turned on by default, i could not find it in the options and my cpu is high
559 2011-09-20 17:08:21 <melvster1> i have only 135k blocks so far ... been running a few hours
560 2011-09-20 17:11:05 <cjdelisle> cpu is relitively high while it gets the blockchain
561 2011-09-20 17:13:36 <melvster1> ok thanks
562 2011-09-20 17:27:54 <Disposition> melvster1: mining fron the default client has been disabled.
563 2011-09-20 17:27:58 <Disposition> or rather removed.
564 2011-09-20 17:28:08 <Disposition> since 0.3.1iirc.
565 2011-09-20 17:28:41 <melvster1> Disposition: thanks, that's good to know .... I'm always careful about whether I've installed the right thing with btc! :)
566 2011-09-20 17:32:34 <Diablo-D3> dont worry
567 2011-09-20 17:32:38 <Diablo-D3> in the end, all of your btc come to me
568 2011-09-20 17:32:59 <melvster1> so long as you spend them wisely, that's OK :P
569 2011-09-20 19:38:14 <Joric> if i want to get into the block asap, should i broadcast the transaction directly to the pool node? say to the deepbit / eligius node?
570 2011-09-20 19:40:32 <phantomcircuit> that would probably help
571 2011-09-20 20:49:16 <diki> what are the max number of blocks that will exist?
572 2011-09-20 20:49:58 <edcba> ;;bc,mtgxo
573 2011-09-20 20:49:58 <gribble> Error: "bc,mtgxo" is not a valid command.
574 2011-09-20 20:50:00 <edcba> ;;bc,mtgox
575 2011-09-20 20:50:01 <gribble> {"ticker":{"high":6.795,"low":5.40102,"avg":6.055547394,"vwap":6.097769271,"vol":116958,"last":6.02866,"buy":6.14361,"sell":6.158}}
576 2011-09-20 20:51:01 <phantomcircuit> diki, there isn't really one
577 2011-09-20 20:56:40 <luke-jr> diki: depends on when Bitcoin dies
578 2011-09-20 21:02:00 <gribble> 146206
579 2011-09-20 21:02:00 <phantomcircuit> ;;bc,blocks
580 2011-09-20 21:24:02 <Joric> may i check the status of my own transaction before it hits the block? e.g. would over clients send it back to me if it's considered valid? would nodes i used for the broadcast send it back to me?
581 2011-09-20 21:25:08 <Namegduf> You shouldn't knowingly be able to generate bad transactions; and the cases you couldn't detect it locally (addresses being modified elsewhere) there's no way for you to know.
582 2011-09-20 21:26:13 <cjdelisle> you should see it in #bitcoin-watch when luke's machine picks it up
583 2011-09-20 21:26:13 <Namegduf> And no real reason to expect the nodes you're directly connected to to know either.
584 2011-09-20 21:27:04 <Namegduf> Technically it could still be a double-spend (the only thing you can't detect locally)
585 2011-09-20 21:27:17 <Namegduf> Admittably unlikely, but it's unlikely to happen anyway.
586 2011-09-20 21:29:27 <Joric> well the node should talk back to me it's not udp after all, i supposed it would tell me if it's going to broadcast this transaction further or not
587 2011-09-20 21:29:58 <gmaxwell> It does not.
588 2011-09-20 21:30:49 <gmaxwell> And that kind of feedback wouldn't be that useful: one hop could be done, but multi-hop has scalablity/DDOS implications.. and if something makes it one hop only to die the next it might as well have just died on the first one.
589 2011-09-20 21:31:10 <gmaxwell> Unless you've modified your node software you won't generate txn that most nodes won't forward.
590 2011-09-20 21:43:14 <copumpkin> comboy_: http://snapplr.com/qzz0
591 2011-09-20 22:52:52 <b4epoche_> yea?
592 2011-09-20 22:53:28 <copumpkin> am I not cool enough for you? :(
593 2011-09-20 22:53:36 <b4epoche_> what?
594 2011-09-20 22:53:56 <b4epoche_> maybe not&  if you're crying over it
595 2011-09-20 22:54:38 <b4epoche_> I'm so cool I was actually headed to bed (at 8:52pm) when you poked me
596 2011-09-20 22:55:01 <copumpkin> oh man
597 2011-09-20 22:55:07 <copumpkin> I'll let you get back to that, then