Latest posts of: jackjack

Show Posts
Pages: « 1 ... 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 [211] 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 ... 291 »

4201

Alternate cryptocurrencies / Altcoin Discussion / Re: [BT3] 5,000 Testnet Bitcoin bounty for Bitcoin Testnet Pool

on: May 22, 2013, 06:15:50 PM

Yay, testnet will be even more difficult to use, congratulations guys!

4202

Local / Hors-sujet / Re: Acheter des fauses bar d'or

on: May 22, 2013, 02:49:44 PM

Je sais pas où on peut en acheter, mais pourquoi ça serait illégal?

4203

Bitcoin / Development & Technical Discussion / Re: Pywallet: manage your wallets/addresses/keys/tx's

on: May 22, 2013, 12:00:22 PM

Yeah I forgot while doing it, I'll make this soon. I never tried with such a passphrase. Try with replacing # with %23. I'll look at that when I'm back home. I think it would just require to put an encodeURIComponent. As for the small size drop, I don't know, it depends how many transactions your wallet contained. Compare the dumps before and after deletion to be sure there's no transaction left.

4204

Bitcoin / Development & Technical Discussion / Re: SIGHASH_LIST proposal

on: May 22, 2013, 09:54:12 AM

I do understand the cost of a hard fork. However, I don't get why that would make this be discussed in the altcoin subforum: I'd like to know what people think about making this possible into Bitcoin, even if it will not implemented in the following months/years Also, such a discussion is the way for people to state the cases that would justify that fork. I wrote the ones I had in mind, but maybe someone will find a great possible improvement coming with SIGHASH_LIST creation Maybe it's not really a 'proposal' but rather a discussion/debate/other

4205

Bitcoin / Development & Technical Discussion / Re: SIGHASH_LIST proposal

on: May 22, 2013, 07:28:13 AM

1. Solves this: Quote there cannot be any change. If you don’t have any outputs of the right size, you must create one first by spending to one of your own addresses. from https://en.bitcoin.it/wiki/Contracts#Example_3:_Assurance_contracts 2. Allows assurance contracts to more than one recipient 3. Provide flexibility: SIGHASH_LIST'd input can have an index > number of outputs 4. Space efficiency: SIGHASH_SINGLE imposes puting as many outputs as inputs even if they are all the same 5. Does this really have to solve anything to be discussed?

4206

Bitcoin / Development & Technical Discussion / SIGHASH_LIST proposal

on: May 21, 2013, 11:27:54 PM

I don't find anything about this, sorry if this was already proposed. I know this would induce a hard fork so it will not be implemented soon anyway. Thus, I'm just collecting opinions/criticisms for now. As you may have understood, SIGHASH_LIST would sign a list of contiguous outputs. It requires two values to work: the index of the first output signed, SI the number of signed outputs, L Those two values would be concatenated after SIGHASH in the scriptSig: DER-sig \| SIGHASH_LIST \| VarInt(SI) \| VarInt(L) However, SI and L are not be signed Here's what its description would look like: Quote Procedure for Hashtype SIGHASH_LIST The first SI output elements of txCopy are deleted. The output of txCopy is resized to L. All other txCopy inputs aside from the current input are set to have an nSequence index of zero. Think of this as "sign some outputs-- I don't care where the other outputs go". Let's make a transaction with that. I redeem 4 BTC from the following transaction: hash=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa index=7 recipient=1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm (hash160=91b24bf9f5288532960ac687abb035127b1d28a5, private key=1) I want to send 1 BTC to each of the following outputs: 2 OP_NUMEQUAL 3 OP_NUMEQUAL And I don't care where other 2 BTC goes The signed data would be: Code: 01000000 =Input= 01 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 07000000 1976a91491b24bf9f5288532960ac687abb035127b1d28a588ac #scriptpubkey ffffffff =Outputs= 02 00e1f50500000000 02519c 00e1f50500000000 02529c 00000000 04000000 #SIGHASH_LIST Only output 1 and output 2 are signed The transaction itself: Code: 01000000 = Input = 01 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 07000000 8e # length of scriptsig 4b # length of signature (SI, L included) 30 # startDER-sig 46 022100b4ae4464627d4c04c862f2cd63c41ff0e9ec4e0613c968c370c5a67cffef0710 022100a09d30bcc1b8104da1e46006aac445027de82be79d5090a452a1436d2476b3b8 04 # SIGHASH_LIST 01 # SI 02 # L 41 # len(pubkey), etc... 04 79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8 ffffffff = Outputs = 04 00e1f50500000000 # amount 0 02509c # scriptpubkey 0 00e1f50500000000 # amount 1 02519c # scriptpubkey 1 00e1f50500000000 # amount 2 02529c # scriptpubkey 2 00e1f50500000000 # amount 3 02539c # scriptpubkey 3 00000000

4207

Bitcoin / Development & Technical Discussion / Re: Pywallet: manage your wallets/addresses/keys/tx's

on: May 21, 2013, 09:44:25 PM

Hey guys The fix for the bug that K1773R found and the BRules' request have been pushed to v2.0.7 CSV files import bug Actually when I coded the CSV import, I did take into account the WIF keys. The bug came from the fact that False!=None.... When trying things, I also noticed that for the keys to be displayed correctly inside bitcoin-qt, you need to use the proper address version. So the CSV files must now have this format: Code: 5KkEy5BZxKi4ZN5n4MUGx1ABSsiGbtNz5hYLBuyaU8dV8iHkBur;label for the key;111 Note1: 111 is for testnet. 0 for Bitcoin. 52 for Namecoin. Etc... Note2: if there is only two columns, version 0 (ie Bitcoin addresses) is implied, so it is backward compatible Multiple deletions at once In the 'key' (renamed 'keys') form, enter: '1address1' to delete that only address (again, backward compatibility) '1address1-1address2-1address3-etc...' to delete a list of addresses divided by '-' BRules, please confirm whether this is faster

4208

Bitcoin / Development & Technical Discussion / Re: Can't redeem simple non-standard transaction on testnet

on: May 21, 2013, 09:00:26 PM

Thanks! I always thought it was other way round

4209

Bitcoin / Development & Technical Discussion / Can't redeem simple non-standard transaction on testnet

on: May 21, 2013, 08:23:23 PM

I made a transaction with this output: "2 OP_ADD 3 OP_NUMEQUALVERIFY" (0x5293539d) But bitcoin-qt throws an error when I try to redeem it with "1" (0x51) Am I missing something?

4210

Bitcoin / Development & Technical Discussion / Re: Block explorer on testnet

on: May 21, 2013, 05:45:42 PM

Self answer: http://testnet.btclook.com But it crashes too, so do you know another one?

4211

Bitcoin / Development & Technical Discussion / Block explorer on testnet

on: May 21, 2013, 05:33:43 PM

Do you know a testnet blockexplorer? Theymos' one is broken... I sent him a PM

4212

Bitcoin / Development & Technical Discussion / Block 237226

on: May 21, 2013, 04:53:33 PM

This block came 19 minutes 28 seconds after the previous one, and the miner didn't include any transaction Bastard

4213

Bitcoin / Development & Technical Discussion / Re: Using a One-time Pad to encrypt a paper wallet Private Keys

on: May 21, 2013, 03:46:27 PM

Quote from: dunand on May 21, 2013, 01:06:39 PM This way a burglar will think this is only a non-funded paper wallet. No, because the checksum won't correspond. The burglar will think the key isn't correctly formatted. Quote from: dunand on May 21, 2013, 01:21:12 PM I also found out that a private key is not completely random. That doesn't make any sense A number can't be random

4214

Bitcoin / Development & Technical Discussion / Re: Plot "block size = f(block height)"

on: May 21, 2013, 12:33:45 PM

Yeah, "they all differ" meant "considering the last 5 I looked at, they all differ"

4215

Bitcoin / Development & Technical Discussion / Re: Plot "block size = f(block height)"

on: May 21, 2013, 11:23:23 AM

Thanks, that's even better Are you sure the sizes are correct? They all differ from the ones in blockexplorer

4216

Alternate cryptocurrencies / Altcoin Discussion / Re: Litecoin: how does the client validate the blockchain?

on: May 21, 2013, 09:24:54 AM

Far too buggy for now

4217

Other / Off-topic / Re: Post your local weather girl

on: May 21, 2013, 07:33:54 AM

Quote from: batcoin on May 20, 2013, 04:45:03 PM Petra Svoboda in case anyone was thinking about a google search... You read my mind sir Cali Morales

4218

Bitcoin / Development & Technical Discussion / Re: F-yeah! (bitcoind port)

on: May 20, 2013, 09:36:33 PM

Wow congratulations! Great piece of work We need this kind of things

4219

Bitcoin / Development & Technical Discussion / Transaction validation

on: May 20, 2013, 09:31:40 PM

Hi, I made a raw transaction that bitcoin-qt validated (returned the hash with sendrawtransaction) and (I think) broadcasted The problem is that the miners don't include it That transaction is quite standard and has 0.03 BTC for fee so I don't get why... Is it possible that bitcoin-qt validates a tx that miners don't accept? I think not because miners use bitcoind too, so the same rules should apply Irrelevant note: it's on testnet

4220

Bitcoin / Development & Technical Discussion / Re: Pywallet: manage your wallets/addresses/keys/tx's

on: May 20, 2013, 08:15:40 PM

Quote from: BRules on May 20, 2013, 07:52:57 PM I will only delete old spent transactions, so, I won't need them anymore, I was worried that the bitcoind could stop working for some reason. bitcoind will still work correctly Quote from: BRules on May 20, 2013, 07:52:57 PM the only problem I'm seeing is that with my wallet of 200000 transactions, it's takin about 11 seconds to remove one transaction. I made a program to remove the transactions and in 3,5 hours it has deleted 1107 transactions. Do you know which part of the delete is causing this delay? Is there a way to remove a batch of transactions at once instead of one by one? Can you delete all transactions or do you have some you want to keep? The problem is that pywallet opens, reads, then writes into a new wallet the remaining data, for each deletion If you need to keep some transactions, I'll write something q&d to read a file containing hashes and delete all the corresponding transactions inside it

Pages: « 1 ... 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 [211] 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 ... 291 »