1 2013-06-30 04:41:50 <petertodd> jgarzik: Turns out you can already do reasonably efficient announce-commit sacrifices: 2d201879608ed2d14c362dff713a6d17d680cb42d5175dfe42e960e94736be04
  2 2013-06-30 04:42:50 <petertodd> jgarzik: The trick is that Solver() defines a pubkey as any PUSHDATA with length >=33 and <=120, significantly more than 65 byte uncompressed keys.
  3 2013-06-30 04:44:57 <petertodd> jgarzik: So my sacrifice tx spends a pubkey scriptSig to a 1-of-2 multisig, one is my digest (my PGP fingerprint) and the other has a well-known secret key. That tx is just 203 bytes in length.
  4 2013-06-30 04:45:53 <petertodd> jgarzik: The announce is a 1-of-3 multisig, with one 120 byte "pubkey", a 83 byte "pubkey", and a real compressed key so I can spend the txout. All totally reasonable.
  5 2013-06-30 04:47:05 <petertodd> jgarzik: of course, you can decide for yourself if it's reasonable that tx's like this one are standard: 72590fcf0d8021bad77826c5008eaca3541f81d212d55bb7c02ec6a4bf584404, 3x120byte pushdata's
  6 2013-06-30 04:47:57 <petertodd> jgarzik: Works for <pubkey> OP_CHECKSIG too: 3b79111ff0bcdede905ee1ffa2e9ea11cce5aa5e9051cfd8d69a788aadc03626
  7 2013-06-30 04:49:37 <petertodd> jgarzik: I found all this while fixing a regression; on git master all those tx's show arguable incorrect addresses throughout bitcoin-qt because CPubKey() is now staticly allocated, ignoring non-std pubkeys of any kind, so the address you see is Hash160("")
  8 2013-06-30 05:01:07 <petertodd> sipa: vout indexes for what exactly? We do need indexes for what transaction spent a given txout.
  9 2013-06-30 05:08:36 <Vinnie_win> holy heck you guys are still hacking this late?
 10 2013-06-30 05:28:14 <melvster> Vinnie_win: early in europe
 11 2013-06-30 05:37:25 <interfect> Hello
 12 2013-06-30 05:38:27 <interfect> This is only tangentially Bitcoin-related, but I thought distributed blockchains would make a cool generic data structure, so I went and implemented them in Python.
 13 2013-06-30 05:38:28 <interfect> https://bitbucket.org/interfect/pybc
 14 2013-06-30 05:39:29 <interfect> Now I'm running up against the fact that network programming is hard, and Bitcoin does lots of clever things re: throwing out old peers and not being DOSed that I'm going to have to replicate
 15 2013-06-30 05:40:59 <interfect> Just figured someone might care.
 16 2013-06-30 05:41:10 <interfect> I'll go stop coding and eat anything today now.
 17 2013-06-30 07:05:42 <CodeShark> the leading symbol of a base58check encoded bitcoin private key is different for uncompressed and compressed public keys despite the fact that in either case the leading byte is 0x80. This is weird...so base58encoding is not unique?
 18 2013-06-30 07:10:42 <wumpus> CodeShark: the isCompressed private keys have an extra 0x01 byte at the end, depending on the endian this could affect the first symbol, but it would be a reliable measure
 19 2013-06-30 07:12:15 <wumpus> NOT be a reliable measure
 20 2013-06-30 07:12:24 <CodeShark> is this an OpenSSL convention?
 21 2013-06-30 07:12:32 <CodeShark> or where is this extra 0x01 byte thing defined?
 22 2013-06-30 07:12:34 <wumpus> eh, no, this has nothing to do with openssl
 23 2013-06-30 07:12:40 <matjeh> CodeShark: different sizes
 24 2013-06-30 07:12:40 <wumpus> some .h file :)
 25 2013-06-30 07:12:54 <CodeShark> if you add an 0x01 to a private key it ceases to encode the same scalar on the elliptic curve
 26 2013-06-30 07:13:10 <wumpus> eh, this is not add, this is more like concatenate
 27 2013-06-30 07:13:18 <CodeShark> I meant concatenate
 28 2013-06-30 07:13:27 <wumpus> it knows the size of the private key, so it can just strip it off again when decoding
 29 2013-06-30 07:13:35 <CodeShark> what knows this?
 30 2013-06-30 07:13:35 <matjeh> its like saying 100h is 256 decimal, but 1000h is 4096 decimal. whoa, one starts with a 2 and the other starts with a 4, but the hex start the same!
 31 2013-06-30 07:13:58 <matjeh> it just number base conversion for different sizes
 32 2013-06-30 07:13:59 <wumpus> the class doing the decoding from base58 to an object
 33 2013-06-30 07:14:02 <CodeShark> that's not my point at all
 34 2013-06-30 07:14:07 <CodeShark> I've been using a base58 encoder/decoder I wrote over a year ago
 35 2013-06-30 07:14:18 <CodeShark> works fine with both "compressed" and "uncompressed" private keys
 36 2013-06-30 07:14:37 <matjeh> CodeShark: are they exactly the same size?
 37 2013-06-30 07:14:45 <CodeShark> so when I pass the bytes for the private key to OpenSSL, how does it know I don't mean a scalar?
 38 2013-06-30 07:14:47 <wumpus> it should , but the compressed will be one byte longer
 39 2013-06-30 07:14:56 <wumpus> and the last byte will be 0x01
 40 2013-06-30 07:15:04 <sipa> CodeShark: private keys are a scalar
 41 2013-06-30 07:15:16 <CodeShark> yes, I'm well aware that that's what they are mathematically
 42 2013-06-30 07:15:22 <sipa> CodeShark: and you dont pass the extra 1 byte to openssl
 43 2013-06-30 07:15:26 <CodeShark> so my question is WHERE is this 0x01 appended encoding defined?
 44 2013-06-30 07:15:28 <interfect> Why is compressed longer than uncompressed? That's not how compression works...
 45 2013-06-30 07:15:48 <wumpus> it knows that the key is 32 bytes, so if it is 33 bytes, AND they last byte is 0x01, it is marked as compessed
 46 2013-06-30 07:16:01 <wumpus> then it just strips that off before passing it to any math
 47 2013-06-30 07:16:11 <CodeShark> so this is an OpenSSL thing
 48 2013-06-30 07:16:16 <sipa> no
 49 2013-06-30 07:16:27 <wumpus> no, this has nothing to do with openssl at all, all this code is in bitcoin
 50 2013-06-30 07:16:53 <CodeShark> BIGNUM* bn = BN_bin2bn(&privateKey[0], PRIVATE_KEY_LENGTH, BN_new());
 51 2013-06-30 07:17:10 <sipa> you do not pass the extra 1 byte to openssl
 52 2013-06-30 07:17:11 <CodeShark> this seems to work whether the priv key is 32 or 33 bytes
 53 2013-06-30 07:17:17 <CodeShark> oh, right
 54 2013-06-30 07:17:35 <CodeShark> PRIVATE_KEY_LENGTH is always 32
 55 2013-06-30 07:17:49 <wumpus> CodeShark: CBitcoinSecret
 56 2013-06-30 07:17:52 <wumpus> in base48.h
 57 2013-06-30 07:17:54 <sipa> interfect: it is not the private key that is compressed
 58 2013-06-30 07:18:20 <sipa> interfect: the extra byte is there to signify that the corresponding public key is to be compressed
 59 2013-06-30 07:18:26 <CodeShark> https://github.com/CodeShark/CoinClasses/blob/master/src/CoinKey.cpp
 60 2013-06-30 07:18:42 <CodeShark> ok, I see
 61 2013-06-30 07:18:50 <wumpus> ret.Set(&vchData[0], &vchData[32], vchData.size() > 32 && vchData[32] == 1);   hehe
 62 2013-06-30 07:19:05 <wumpus> I had a lot of trouble finding it too the first time
 63 2013-06-30 07:19:10 <CodeShark> so to get the wallet import form for compressed pubkeys, I append a 0x01 before base58 encoding
 64 2013-06-30 07:19:19 <sipa> indeed
 65 2013-06-30 07:19:43 <CodeShark> time to add that detail to the wiki :)
 66 2013-06-30 07:21:01 <sipa> oh yes please
 67 2013-06-30 07:22:09 <CodeShark> why was that done rather than, say, just picking a different version byte?
 68 2013-06-30 07:22:42 <sipa> because i wanted to keep private keys and addresses corresponding
 69 2013-06-30 07:22:55 <CodeShark> I had a validation line in my code that before this moment I didn't understand why I had to change to get newer bitcoind to work with it
 70 2013-06-30 07:23:02 <CodeShark> if ((privateKey.size() == PRIVATE_KEY_LENGTH) || (privateKey.size() == PRIVATE_KEY_LENGTH + 1))
 71 2013-06-30 07:23:08 <CodeShark> lol
 72 2013-06-30 07:23:23 <sipa> so that one version byte for an address corresponds to one version byte for keys
 73 2013-06-30 07:23:38 <sipa> perhaps it is too much of a mess now to bother about that
 74 2013-06-30 07:24:09 <CodeShark> oh, right - OpenSSL is using the opposite endian
 75 2013-06-30 07:24:14 <CodeShark> so appending right?
 76 2013-06-30 07:24:45 <CodeShark> lol - you broke my code, sipa!
 77 2013-06-30 07:24:54 <CodeShark> and I fixed it but I had no idea why it had changed
 78 2013-06-30 07:25:06 <sipa> appending?
 79 2013-06-30 07:25:19 <CodeShark> nvm
 80 2013-06-30 07:25:21 <sipa> openssl uses big endian everywhere
 81 2013-06-30 07:25:29 <sipa> it is the standard in crypto i think
 82 2013-06-30 07:25:41 <CodeShark> disregard the endian comment
 83 2013-06-30 07:26:17 <CodeShark> anyhow, now I need to add a special case in each of my functions to deal with this :p
 84 2013-06-30 07:26:25 <CodeShark> rather than just getWalletImport(versionByte)
 85 2013-06-30 07:26:45 <sipa> depends
 86 2013-06-30 07:27:19 <sipa> whether the object that ,ethod applies to knows whether the pubkey is to be compressed or not
 87 2013-06-30 07:27:56 <CodeShark> OpenSSL wouldn't care either way - but I don't want something to break later on
 88 2013-06-30 07:28:12 <CodeShark> some of this is used for interactive tools
 89 2013-06-30 07:28:21 <sipa> i do not understand what openssl has to do with it
 90 2013-06-30 07:28:28 <sipa> it shoukdnt even know
 91 2013-06-30 07:28:34 <CodeShark> I'm saying openssl doesn't care either way
 92 2013-06-30 07:28:41 <CodeShark> but the user tools do
 93 2013-06-30 07:28:51 <sipa> about what?
 94 2013-06-30 07:29:00 <CodeShark> about which encoding is used
 95 2013-06-30 07:29:26 <sipa> indeed
 96 2013-06-30 07:29:34 <sipa> but were talking about private keys here
 97 2013-06-30 07:30:19 <CodeShark> yes - it means that unless you store the public keys along with them, to regenerate the public keys you need to make sure you can distinguish the two versions
 98 2013-06-30 07:30:45 <CodeShark> and it's not simply a matter of checking the version byte anymore
 99 2013-06-30 07:30:51 <CodeShark> now there's a second check for length
100 2013-06-30 07:30:55 <sipa> yes, since a recent refactor the CKey object has a boolean flag
101 2013-06-30 07:31:13 <sipa> to remember whether the corresponding pubkey is compressed or not
102 2013-06-30 07:31:34 <sipa> before that boolean was always managed separately by the calling code
103 2013-06-30 07:31:39 <sipa> which was very ugly
104 2013-06-30 07:32:39 <sipa> so if you see a private key as a 32-byte secret parameter + that boolean, it all works fine
105 2013-06-30 07:32:47 <CodeShark> and it's also necessary to check that if it's 33 bytes, the last one is 0x01
106 2013-06-30 07:33:01 <CodeShark> and if other encodings start to use other final bytes, it gets even more complex
107 2013-06-30 07:33:06 <CodeShark> altcoins
108 2013-06-30 07:35:11 <CodeShark> I still don't understand the decision not to just use a different version byte :p
109 2013-06-30 07:36:50 <CodeShark> perhaps the base58encoding document in the wiki should be updated - and we should extend it to also support appending codes, not just prepending
110 2013-06-30 07:37:29 <CodeShark> call the last byte the "subversion byte" or something
111 2013-06-30 07:37:44 <CodeShark> it's getting pretty ugly, though :)
112 2013-06-30 07:38:36 <CodeShark> getWalletImport(versionByte, subVersionBytes) and the second parameter can be empty
113 2013-06-30 07:41:51 <CodeShark> the table https://en.bitcoin.it/wiki/List_of_address_prefixes should contain both the versionByte and the subVersionBytes as columns
114 2013-06-30 07:42:48 <CodeShark> of course, the subVersionBytes cannot be read from a given arbitrary base58 string unless we know the length of the data it encodes
115 2013-06-30 07:43:12 <CodeShark> so perhaps subVersionBytes is not the right name
116 2013-06-30 07:43:21 <CodeShark> appendedBytes
117 2013-06-30 07:44:28 <CodeShark> string_secure CoinKey::getWalletImport(unsigned char versionByte, const uchar_vector& appendedBytes) const
118 2013-06-30 07:44:30 <CodeShark> lol
119 2013-06-30 07:44:40 <CodeShark> now it supports everything again
120 2013-06-30 07:44:59 <sipa> why not make the compression flag a property of CoinKey
121 2013-06-30 07:46:00 <CodeShark> I guess this appending is only being used for private keys...so yeah, you're right
122 2013-06-30 07:46:09 <CodeShark> I was thinking about base58check encoding more generally
123 2013-06-30 07:46:16 <sipa> well yes
124 2013-06-30 07:46:38 <sipa> if you have a base58checkencoder, it makes sense to give a prefix and suffix bytes
125 2013-06-30 07:47:03 <sipa> but not at the level of the data structurrs where those bytes get a meaning
126 2013-06-30 07:47:31 <sipa> i mean... the point was exactly that the version byte could be independent from this
127 2013-06-30 07:48:04 <CodeShark> ok, I see what you mean
128 2013-06-30 07:48:25 <CodeShark> it works in this case because the underlying data can be unambiguously discerned
129 2013-06-30 07:48:44 <CodeShark> if you had some underlying datatype of variable length it wouldn't work
130 2013-06-30 07:49:27 <sipa> btw, bip32 has 4-byte prefixes :)
131 2013-06-30 07:49:37 <sipa> to complicate matters further
132 2013-06-30 07:50:49 <walch> that's probable
133 2013-06-30 07:51:36 <sipa> 100%
134 2013-06-30 07:56:54 <walch> alright, so I've read through a lot of the early forum posts, and I still can't find much information on contributing non-code assets to the bitcoin project. can anybody give me some pointers?
135 2013-06-30 08:00:00 <walch> ideally I'd like to be able to propose some changes to the bitcoin-qt interface, if that's possible.
136 2013-06-30 08:00:52 <sipa> you can file an issue
137 2013-06-30 08:01:12 <sipa> github.com/bitcoi/bitcoin/issues
138 2013-06-30 08:04:42 <walch> sipa: alright, thanks. it looks like a lot of discussion goes on there (I wasn't expecting that)
139 2013-06-30 08:09:58 <michagogo> walch: (add a n to sipa
140 2013-06-30 08:10:01 <michagogo> 's link)
141 2013-06-30 08:14:37 <walch> michagogo: I'd already come across the page actually, just wasn't sure if it was the right place to discuss non-code things
142 2013-06-30 08:14:55 <walch> michagogo: thanks though
143 2013-06-30 08:20:48 <signor777> I tried to create a transaction from a multi-sig address, but I'm not able to sign it. Can anyone tell me what I'm doing wrong? http://pastebin.com/gkqF2Lh8
144 2013-06-30 08:21:20 <signor777> (you can keep the 0.0095 BTC if you tell me how you spent them)
145 2013-06-30 08:21:34 <michagogo> signor777: y u no testnet
146 2013-06-30 08:21:42 <signor777> yeah i know :)
147 2013-06-30 08:21:46 <signor777> next time for sure
148 2013-06-30 08:22:31 <signor777> michagogo: sorry for bloating the blockchain with my stupid tests :)
149 2013-06-30 08:22:45 <michagogo> signor777: More that you shouldn't be dealing with real money
150 2013-06-30 08:22:55 <michagogo> for testing
151 2013-06-30 08:24:24 <signor777> michagogo: I know, but i can afford to lose $1... And it's a nice incentive for people to help me.
152 2013-06-30 08:31:10 <michagogo> I don't think I fully understand what I'm seeing here
153 2013-06-30 08:31:44 <CodeShark> signor777: believe it or not, I actually just wrote a tool to do this yesterday :)
154 2013-06-30 08:32:48 <CodeShark> you need to specify the redeem script prior to signing
155 2013-06-30 08:32:59 <CodeShark> the txin has to have the redeem script as scriptSig
156 2013-06-30 08:33:53 <sipa> huh?
157 2013-06-30 08:34:13 <sipa> CodeShark: isn't that only the case in your tools?
158 2013-06-30 08:34:36 <sipa> bitcoind constructs the entire scriptSig in signrawtransaction, afaik
159 2013-06-30 08:34:41 <michagogo> What's the 3GfgMGUCsF6Dv2gZLjhy6bqC4RxRTEHcJ3 address used for?
160 2013-06-30 08:34:50 <michagogo> And what's the 37Fc6k2CrkmBPGsrqyHFPp2Fy9RfKm1fUy address?
161 2013-06-30 08:34:55 <CodeShark> signor777 is passing the redeemscript to signrawtransaction
162 2013-06-30 08:35:31 <michagogo> 4cfcdc4c8bd4502d37c8745538f19972434d1c72cb23e9ca0454103ef653ae"}]' '{"1Bjaewgk3bXujiJUqLcrkk7aKSS1f9kUV3":0.0095}'
163 2013-06-30 08:35:31 <michagogo> Also, {13-06-29 22:11}Linux-T400s:~ rvoellmy% bitcoind createrawtransaction '[{"txid":"12af315cdba24e9fd070a7579135d5ade458b5e71008b0421dcc6bb8a795b3cb","vout":0,"scriptPubKey":"a9143d0277df5a51360d0b2d68bbbbf7ed784601f30587","redeemScript":"522102b55624dd872a0b3db3cf053dacd2960cfe909db3a5405353f95631cfc297dda22103f74a2c52d87c81c589775510ff1d6743f4ab2529a7206cc28762f1559d716ada21024e43b9
164 2013-06-30 08:35:39 <michagogo> If that works, it's not documented
165 2013-06-30 08:35:43 <CodeShark> I was having problems with signrawtransaction as well a few days ago
166 2013-06-30 08:35:51 <CodeShark> which was one of the reasons I started working on these tools :)
167 2013-06-30 08:36:00 <michagogo> Also, {13-06-29 22:11}Linux-T400s:~ rvoellmy% bitcoind createrawtransaction '[{"txid":"12af315cdba24e9fd070a7579135d5ade458b5e71008b0421dcc6bb8a795b3cb","vout":0,"scriptPubKey":"a9143d0277df5a51360d0b2d68bbbbf7ed784601f30587","redeemScript":"522102b55624dd872a0b3db3cf053dacd2960cfe909db3a5405353f95631cfc297dda22103f74a2c52d87c81c589775510ff1d6743f4ab2529a7206cc28762f1559d716ada21024e43b9
168 2013-06-30 08:36:01 <michagogo> 4cfcdc4c8bd4502d37c8745538f19972434d1c72cb23e9ca0454103ef653ae"}]' '{"1Bjaewgk3bXujiJUqLcrkk7aKSS1f9kUV3":0.0095}'
169 2013-06-30 08:36:12 <michagogo> If that works properly, it's not documented
170 2013-06-30 08:36:33 <michagogo> `help createrawtransaction` says it just takes [{"txid":txid,"vout":n},...] and {address:amount,...}
171 2013-06-30 08:37:07 <CodeShark> yeah, it's not well documented and that's not really the way it should work anyhow
172 2013-06-30 08:38:26 <CodeShark> in signor777's example, decoderawtransaction isn't showing anything for the vin scriptSig
173 2013-06-30 08:38:44 <michagogo> I noticed that.
174 2013-06-30 08:42:59 <signor777> CodeShark: is your tool on github?
175 2013-06-30 08:43:07 <CodeShark> yes
176 2013-06-30 08:43:12 <CodeShark> I'll give you a link in a few moments
177 2013-06-30 08:43:55 <michagogo> CodeShark: Is it on https://github.com/CodeShark?tab=repositories ?
178 2013-06-30 08:43:59 <CodeShark> yes
179 2013-06-30 08:44:01 <signor777> thx
180 2013-06-30 08:44:04 <CodeShark> just fixing a minor issue
181 2013-06-30 08:47:27 <signor777> michagogo: Where do you see 37Fc6k2CrkmBPGsrqyHFPp2Fy9RfKm1fUy?
182 2013-06-30 08:47:47 <michagogo> signor777: https://blockchain.info/tx/12af315cdba24e9fd070a7579135d5ade458b5e71008b0421dcc6bb8a795b3cb
183 2013-06-30 08:47:52 <signor777> michagogo: I've created 2 different multi sig adresses, maybe i mixed them up
184 2013-06-30 08:49:14 <signor777> michagogo: ah damn, I'm an idiot. The coins were sent to this address I created earlier. It was created using the same priv/pub keys though
185 2013-06-30 08:49:40 <CodeShark> ok, just pushed the latest version of the tool
186 2013-06-30 08:50:04 <CodeShark> https://github.com/CodeShark/CoinClasses/tree/master/examples/txbuilder
187 2013-06-30 08:50:25 <CodeShark> sorry about the poor documentation at this point
188 2013-06-30 08:50:40 <CodeShark> if you have any questions about it I'd be glad to answer them
189 2013-06-30 08:51:46 <michagogo> signor777: So those BTC you sent are in the other address.
190 2013-06-30 08:52:58 <signor777> michagogo: yes. but i created the address with the same keys, so it shouldn't matter, right?
191 2013-06-30 08:53:28 <CodeShark> the redeemscript must be the same
192 2013-06-30 08:53:39 <CodeShark> so the order of the keys matters
193 2013-06-30 08:58:59 <CodeShark> createmultisig 2 024e43b94cfcdc4c8bd4502d37c8745538f19972434d1c72cb23e9ca0454103ef6 03f74a2c52d87c81c589775510ff1d6743f4ab2529a7206cc28762f1559d716ada 02b55624dd872a0b3db3cf053dacd2960cfe909db3a5405353f95631cfc297dda2
194 2013-06-30 08:59:04 <CodeShark> that's the correct permutation
195 2013-06-30 08:59:46 <michagogo> signor777: Looks to me like you're passing just one privkey into signrawtransaction
196 2013-06-30 09:00:47 <michagogo> Though you shouldn't need any of those if they're in your wallet
197 2013-06-30 09:00:49 <signor777> michagogo: Yeah thats right, but that should still work and partially sign the transaction. But it doesn't
198 2013-06-30 09:01:55 <signor777> michagogo: yeah i know but i was just trying to test this, because I'm planning on keeping a large amount of coins in a multi sig address, with the private keys distributed among different people
199 2013-06-30 09:02:17 <michagogo> Also, I think '[{"txid":"12af31....","vout":0,"scriptPubKey":"a9143d02....","redeemScript":"52210...."}]' isn't necessary when it's spending a tx already in blockchain
200 2013-06-30 09:02:29 <michagogo> (in signrawtransaction)
201 2013-06-30 09:04:57 <signor777> michagogo: ah ok, good to know
202 2013-06-30 09:05:25 <michagogo> "Second optional argument (may be null) is an array of previous transaction outputs that
203 2013-06-30 09:05:25 <michagogo> this transaction depends on but may not yet be in the block chain."
204 2013-06-30 09:14:50 <CodeShark> signor777: http://pastebin.com/W0zCLB6i
205 2013-06-30 09:15:00 <CodeShark> all the steps except sendrawtransaction
206 2013-06-30 09:16:55 <CodeShark> sorry about the poor formatting
207 2013-06-30 09:18:58 <signor777> CodeShark: awesome, thanks!
208 2013-06-30 09:19:32 <CodeShark> the tool can be used in two modes - with the built-in command interpreter or just at the command line
209 2013-06-30 09:21:42 <CodeShark> it's still really, really rough around the edges :p
210 2013-06-30 09:37:27 <signor777> CodeShark: what's <txblob>?
211 2013-06-30 09:38:12 <CodeShark> the serialized full object
212 2013-06-30 09:38:31 <CodeShark> the tool supports attaching dependency transactions to the transaction you're signing
213 2013-06-30 09:38:53 <sipa> for some reason my gitian doesn't use HW accel anymore in 32-bit mode :(
214 2013-06-30 09:39:16 <CodeShark> most operations require the transaction to remain in SCRIPT_SIG_EDIT mode, which means placeholders are kept for missing signatures
215 2013-06-30 09:39:37 <CodeShark> at the very end, the command getbroadcast strips away the remaining placeholders
216 2013-06-30 09:40:10 <CodeShark> in the built-in command interpreter, % means "the output of the last command"
217 2013-06-30 09:40:53 <CodeShark> so you can do stuff like > addinput % .... > addoutput % ...., etc...
218 2013-06-30 09:47:19 <signor777> CodeShark: ah ok, cool
219 2013-06-30 09:48:13 <signor777> CodeShark: everything seems to work great, but when i try to broadcast the transaction i get error: {"code":-22,"message":"TX rejected"}
220 2013-06-30 09:48:31 <signor777> what is error -22? This code is not listed in the wiki
221 2013-06-30 09:48:58 <sipa> it means the mempool doesn't accept that transaction
222 2013-06-30 09:49:06 <sipa> so some validation rule failed
223 2013-06-30 09:49:28 <CodeShark> signor777, check the log for more detauls
224 2013-06-30 09:49:34 <CodeShark> *details
225 2013-06-30 09:49:37 <CodeShark> I'm guessing
226 2013-06-30 09:49:44 <CodeShark> ValidateSignature failed
227 2013-06-30 09:55:18 <signor777> CodeShark: Log just says "ERROR: CTxMemPool::accept() : nonstandard transaction input"
228 2013-06-30 09:55:36 <CodeShark> can you give me the serialized hex?
229 2013-06-30 09:55:46 <signor777> 0100000001cbb395a7b86bcc1d42b00810e7b558e4add5359157a770d09f4ea2db5c31af1200000000fd000100483045022100c0883f057d8e30c3e086fee31b0c7893ce76b4e287c4100984afc1797198037102201bb5193c3eb77d78fed3ea91ca75c916be215263332b13b427b5471b5de255d501493046022100bd6197b3107a24dfcc62d1f9953af55a48ad93edfc2bfd39decaa915f4d403c90221009543534c212e104b74d637a8badc206f1de92b82c56df7fc63b72b5cc623a47e01004c695221024e43b94cfcdc4c8bd4502d37c8745538f
230 2013-06-30 09:56:08 <michagogo> 2013-06-30 11:52:27 ERROR: CScriptCheck() : 9c8a2f982aaa82162676c5a1a9836c0890511ee8fad5c171bbac3da7c84fe941 VerifySignature failed
231 2013-06-30 09:56:08 <michagogo> 2013-06-30 11:52:27 ERROR: CTxMemPool::accept() : ConnectInputs failed 9c8a2f982aaa82162676c5a1a9836c0890511ee8fad5c171bbac3da7c84fe941
232 2013-06-30 09:56:40 <michagogo> That's on line 84 from http://pastebin.com/W0zCLB6i
233 2013-06-30 09:56:58 <michagogo> signor777: Your line got truncated
234 2013-06-30 09:57:12 <sipa> put it on a paste site
235 2013-06-30 09:57:42 <signor777> http://pastebin.com/khbCPFqk
236 2013-06-30 09:58:14 <michagogo> 2013-06-30 11:53:50 ERROR: CTxMemPool::accept() : nonstandard transaction type
237 2013-06-30 09:58:21 <CodeShark> that last one is still in SIG_SCRIPT_EDIT format
238 2013-06-30 09:58:31 <CodeShark> you need to strip away the last signature placeholder
239 2013-06-30 09:58:38 <michagogo> Erm, sorry -- wrong line
240 2013-06-30 09:58:39 <michagogo> 2013-06-30 11:54:39 ERROR: CTxMemPool::accept() : nonstandard transaction input
241 2013-06-30 09:58:56 <CodeShark> right, nonstandard transaction input means it's not in broadcast format
242 2013-06-30 09:59:14 <CodeShark> VerifySignature failed means either you signed the wrong thing or used the wrong signature
243 2013-06-30 09:59:32 <michagogo> http://pastebin.com/feXJMnbM
244 2013-06-30 09:59:34 <CodeShark> s/signature/privkey
245 2013-06-30 10:00:35 <michagogo> CodeShark: That's pulling from your pastebin
246 2013-06-30 10:00:50 <CodeShark> it's possible I screwed something up :p
247 2013-06-30 10:01:24 <CodeShark> I need to add partial validation to the tool so you can see when you screw up right away :)
248 2013-06-30 10:01:58 <CodeShark> gonna try again to do it step-by-step
249 2013-06-30 10:03:03 <michagogo> (signor777 == omnibrain)?
250 2013-06-30 10:05:08 <signor777> CodeShark: No you're right, i forgot the getbroadcast command but it still doesn't work
251 2013-06-30 10:05:27 <signor777> http://pastebin.com/pe1P0JtG
252 2013-06-30 10:05:40 <signor777> michagogo: yes :)
253 2013-06-30 10:07:29 <CodeShark> I used the wrong privkey for the first signature
254 2013-06-30 10:07:38 <signor777> CodeShark: now I'm getting this: ERROR: CScriptCheck() : 9c8a2f982a VerifySignature failed \\n ERROR: CTxMemPool::accept() : ConnectInputs failed 9c8a2f982a
255 2013-06-30 10:07:40 <CodeShark> redoing all the steps
256 2013-06-30 10:07:48 <CodeShark> I'll do another pastebin when I have it
257 2013-06-30 10:08:22 <CodeShark> my tool still doesn't check whether the privkey and pubkey correspond - I should add that
258 2013-06-30 10:11:13 <CodeShark> alright, signor777: http://pastebin.com/59rkbdWV
259 2013-06-30 10:12:06 <signor777> CodeShark: Oh damn I also used a wrong key :D
260 2013-06-30 10:12:58 <CodeShark> I'll add that validation and push the update
261 2013-06-30 10:15:17 <michagogo> Odd, that transaction's also being rejected
262 2013-06-30 10:15:22 <michagogo> With no error
263 2013-06-30 10:15:46 <CodeShark> the log shows no error?
264 2013-06-30 10:16:06 <CodeShark> I'd try submitting but as soon as one of us succeeds that transaction is useless :)
265 2013-06-30 10:16:37 <CodeShark> ok, I pushed a fix to the tool
266 2013-06-30 10:16:44 <michagogo> No error afaict
267 2013-06-30 10:16:55 <michagogo> One sec, let me plug it into decode and get the txid
268 2013-06-30 10:17:10 <CodeShark> https://blockchain.info/address/37Fc6k2CrkmBPGsrqyHFPp2Fy9RfKm1fUy
269 2013-06-30 10:17:17 <michagogo> Ah
270 2013-06-30 10:17:19 <CodeShark> :)
271 2013-06-30 10:17:22 <michagogo> Looks like someone already sent it
272 2013-06-30 10:17:31 <CodeShark> wasn't me
273 2013-06-30 10:17:36 <CodeShark> so must have been one of you two :)
274 2013-06-30 10:17:36 <michagogo> 2013-06-30 12:09:51 CTxMemPool::accept() : accepted abd807c71e55d608ab574bc482db882fa370b9242d36d4f25c2d3adfc2c5b459 (poolsz 431)
275 2013-06-30 10:17:36 <michagogo> 2013-06-30 12:09:51 received getdata for: tx abd807c71e55d608ab574bc482db882fa370b9242d36d4f25c2d3adfc2c5b459
276 2013-06-30 10:17:40 <michagogo> Not me
277 2013-06-30 10:18:07 <CodeShark> so yeah, the only problem in the first pastebin was that I used the wrong private key for the first signature
278 2013-06-30 10:18:14 <CodeShark> that shouldn't be possible anymore
279 2013-06-30 10:18:20 <CodeShark> the tool complains if you try to do that
280 2013-06-30 10:25:11 <signor777> CodeShark: Awesome. Thanks for your help!
281 2013-06-30 10:25:22 <signor777> I didn't send it either, btw :)
282 2013-06-30 10:25:27 <CodeShark> hah
283 2013-06-30 10:25:35 <CodeShark> sure, no problem, signor777 :)
284 2013-06-30 10:25:59 <CodeShark> you happened to ask me at the right time - I've been heavily focused on this exact problem the last couple days :)
285 2013-06-30 10:26:41 <CodeShark> I'll probably forget all of this in a few weeks :p
286 2013-06-30 10:26:59 <signor777> lucky me :)
287 2013-06-30 10:40:23 <signor777> CodeShark: I think I found a little bug: calling addmofninput directly from bash doesn't work. See here: http://pastebin.com/dmjBCp9f , the same command run in the console works fine
288 2013-06-30 10:40:48 <CodeShark> oh, right - it's the null parameter
289 2013-06-30 10:40:53 <CodeShark> from bash you need to use ''
290 2013-06-30 10:41:05 <signor777> ah ok
291 2013-06-30 10:42:06 <CodeShark> I added the substitution in the command interpreter because I was too lazy to correctly parse quotes :p
292 2013-06-30 11:19:15 <grau> in case somebody needs a testnet explorer, I set up a simple one at http://bitsofproof.com/?page_id=304
293 2013-06-30 12:29:48 <bitanarchy> i notice that bitcoin-qt configured to use a proxy... still connects to the bitcoin network even if the proxy is down... that's weird
294 2013-06-30 12:31:04 <sipa> outgoing connections?
295 2013-06-30 12:31:23 <sipa> or ipv6 cobnections
296 2013-06-30 12:31:59 <bitanarchy> sipa: offcourse i am worried about outgoing connections.. because they should go over tor
297 2013-06-30 12:32:10 <sipa> sure
298 2013-06-30 12:32:45 <sipa> so what config options are you using, and what do you observe?
299 2013-06-30 12:33:34 <bitanarchy> site: i get connected nodes even though tor is down... and i use a proxy
300 2013-06-30 12:33:53 <bitanarchy> i want to reproduce... but my chatclient is also on tor :)
301 2013-06-30 12:33:58 <sipa> define "i use a proxy"
302 2013-06-30 12:34:09 <sipa> and define "get connected nodes"
303 2013-06-30 12:34:38 <sipa> just connections is possible if other nodes can reach you
304 2013-06-30 12:34:39 <Vinnie_win> wow hardcore hours
305 2013-06-30 12:35:00 <bitanarchy> i checked options->network->connect through a socks proxy
306 2013-06-30 12:35:04 <sipa> or if the proxy is only set for ipv4, and you have ipv6 peers
307 2013-06-30 12:35:10 <bitanarchy> and restarted
308 2013-06-30 12:35:41 <sipa> can you do a get getpeerinfo ?
309 2013-06-30 12:36:01 <bitanarchy> sipa: i don't think i have ipv6....
310 2013-06-30 12:36:08 <sipa> right, qt, unsure about the exact semantics there
311 2013-06-30 12:36:35 <sipa> well getpeerinfo should make it clear
312 2013-06-30 12:39:42 <bitanarchy> my peers are ip4 but i cannot see if they are reached via the proxy
313 2013-06-30 12:48:00 <sipa> can you paste the output somewhere?
314 2013-06-30 12:48:53 <bitanarchy> i get it... i stopped vidalia... but apparently not tor
315 2013-06-30 12:49:23 <bitanarchy> i installed tor on linux and also the tor browser
316 2013-06-30 12:50:59 <bitanarchy> does vidalia have its own tor proxy??
317 2013-06-30 12:51:23 <sipa> no clue
318 2013-06-30 13:00:38 <michagogo> bitanarchy: Pretty sure bitcoin-qt has a tor-only mode
319 2013-06-30 13:00:49 <michagogo> Some flag or something that restricts it to .onions
320 2013-06-30 13:05:00 <Subo1978> bitanarchy: jes
321 2013-06-30 13:07:16 <sipa> -onlynet=tor
322 2013-06-30 13:16:31 <sci7> Hey - I'm interested in contributing to bitcoin and I was wondering if there was some documentation about where to start? I have a fork of the bitcoin source tree installed - is there a list of open issues somewhere?
323 2013-06-30 13:17:13 <shesek> https://github.com/bitcoin/bitcoin/issues?state=open ?
324 2013-06-30 13:17:36 <sci7> thanks - relatively new to github.
325 2013-06-30 13:17:48 <shesek> you can filter by labels on the left
326 2013-06-30 13:18:02 <shesek> e.g. https://github.com/bitcoin/bitcoin/issues?labels=Feature to see all feature requests
327 2013-06-30 13:18:17 <shesek> or https://github.com/bitcoin/bitcoin/issues?labels=Bug for open bugs
328 2013-06-30 13:18:31 <sci7> Thanks very much
329 2013-06-30 13:18:54 <shesek> you welcome
330 2013-06-30 13:50:35 <michagogo> sci7: I assume you're familiar with the "fork, hack, commit, push, PR" workflow?
331 2013-06-30 14:08:05 <sci7> michagogo: to an extent - at work we're just moving to git from cvs, so some of this is new to me, some less so
332 2013-06-30 14:10:43 <BCB> is bitcoin a "virtual" or a "digital" currency and what is the connation of each /join #bitcoin
333 2013-06-30 14:12:22 <sipa> BCB: it'd say it's a purely digital currency - it's no less virtual than the dollar or the euro (except used on much smaller scale)
334 2013-06-30 14:12:36 <sipa> and 'connation' ?
335 2013-06-30 14:12:56 <BCB> sipa some say calling bitcoin virtual currency has a negative connotation
336 2013-06-30 14:13:08 <BCB> Governments have taken to calling bitcoin virtual currency
337 2013-06-30 14:13:10 <sipa> i agree, but i don't care
338 2013-06-30 14:13:19 <BCB> sipa: semantics are important
339 2013-06-30 14:13:25 <BCB> in law and debate
340 2013-06-30 14:13:35 <BCB> I'm just looking for opinion
341 2013-06-30 14:13:39 <sipa> that's why i'm no lawyer :)
342 2013-06-30 14:14:13 <BCB> I'm not asking in bitcoin-law
343 2013-06-30 14:14:34 <sipa> from my point of view it defines a digital commodity
344 2013-06-30 14:14:43 <BCB> what does?
345 2013-06-30 14:14:46 <sipa> bitcoin
346 2013-06-30 14:14:57 <BCB> bitcoin is a digital commodity
347 2013-06-30 14:15:18 <sipa> bitcoin-the-technology defines a digital commodity bitcoin-the-unit
348 2013-06-30 14:15:27 <sipa> is what i mean :)
349 2013-06-30 14:15:58 <BCB> over my head
350 2013-06-30 14:16:05 <BCB> repeat in laymans terms
351 2013-06-30 14:16:27 <BCB> pls
352 2013-06-30 14:17:21 <sipa> "bitcoin" both refers to 1) a computer program, 2) a protocol that program speaks, 3) a network consisting of computers running that program, and 4) a currency that can be transferred using that program
353 2013-06-30 14:19:17 <BCB> ahhh ha!
354 2013-06-30 14:19:21 <BCB> more semantics
355 2013-06-30 14:19:26 <BCB> this is important
356 2013-06-30 14:19:32 <BCB> can i pm you
357 2013-06-30 14:19:52 <sipa> i'm about to run off, but perhaps there are others here who like to discuss this :)
358 2013-06-30 14:21:21 <BCB> doesn't look like it but thanks for you input.  Will you be in london tuesday
359 2013-06-30 14:21:34 <sipa> no
360 2013-06-30 14:21:40 <sipa> too businessy, from what i understand :)
361 2013-06-30 14:22:02 <BCB> yes
362 2013-06-30 14:53:49 <skinnkavaj> sipa
363 2013-06-30 14:54:10 <skinnkavaj> where can i see a list of how many gh/s 1 th/s is etc
364 2013-06-30 14:54:26 <skinnkavaj> gmaxwell maybe know
365 2013-06-30 14:55:09 <sipa> are you serious?
366 2013-06-30 14:55:22 <sipa> 1k = 1000
367 2013-06-30 14:55:24 <sipa> 1M = 1000k
368 2013-06-30 14:55:28 <sipa> 1G = 1000M
369 2013-06-30 14:55:31 <sipa> 1T = 1000G
370 2013-06-30 14:55:34 <sipa> 1P = 1000T
371 2013-06-30 14:56:57 <tcatm> sipa: I've updated the pull request. There are references to "wallet.dat" in some strings and I wonder whether I should update them, too.
372 2013-06-30 14:57:12 <sipa> tcatm: thanks
373 2013-06-30 14:57:30 <sipa> tcatm: well, i suppose all that will eventually go away with multiwallet support anyway
374 2013-06-30 15:07:56 <denisx> skinnkavaj: http://en.wikipedia.org/wiki/Metric_prefix
375 2013-06-30 16:34:34 <BCB> sipa is bitcoin e-money
376 2013-06-30 16:59:32 <michagogo> Question: Is bitcoin registered as a group with freenode?
377 2013-06-30 17:07:34 <TheLordOfTime> michagogo:  i betcha nanotube would know the answer to that.  or jgarzik or gavinandresen or Keefe, namely since they have founder flags on #bitcoin, which would need to be groupregistered
378 2013-06-30 17:08:00 <TheLordOfTime> but... if it's not group registered i don't think there's open group registrations, i haven't seen anything on freenode's staffblog saying they've reopened group registration
379 2013-06-30 17:08:06 <TheLordOfTime> (sorry for the mass highlight)
380 2013-06-30 17:10:06 <nsh> ACTION frowns
381 2013-06-30 17:10:28 <nsh> per freenode policy #bitcoin must be "officially" a project as it's in a the single hash namespace
382 2013-06-30 17:10:40 <nsh> s/a //
383 2013-06-30 17:11:37 <TheLordOfTime> nsh:  but here's the point: nobody follows that
384 2013-06-30 17:11:45 <TheLordOfTime> ther'es 'a thousand plus # channels in the wrong namespace
385 2013-06-30 17:11:52 <TheLordOfTime> as it stands freenode doesn't enforce it
386 2013-06-30 17:11:57 <TheLordOfTime> but... they're there
387 2013-06-30 17:12:06 <nsh> sure, also it's stupid. :)
388 2013-06-30 17:12:09 <TheLordOfTime> come GMS (Group Mangement System) enforcement will be automated
389 2013-06-30 17:12:23 <TheLordOfTime> at least, last time i poked around about it
390 2013-06-30 17:34:10 <sipa> TheLordOfTime: afaik jgarzik owns #bitcoin, by making a commit in the bitcoin github repo proving he has write access
391 2013-06-30 17:34:35 <TheLordOfTime> sipa:  then jgarzik can confirm/refute group registration on freenode :)
392 2013-06-30 17:34:41 <TheLordOfTime> afaict he's connected :)
393 2013-06-30 17:34:59 <TheLordOfTime> either way, the point still stands that as normal mortals we won't know :P
394 2013-06-30 17:35:43 <michagogo> AFAIK it's not that #channels must be group-registered at the moment, considering that there's no group registrations
395 2013-06-30 17:36:05 <michagogo> And I saw there's a freenode verification branch on github
396 2013-06-30 17:37:00 <michagogo> The only question is whether it's an *actual* group registration from back when grf/grf-f entries were open, or if staff just gave him the channel flags
397 2013-06-30 17:39:05 <michagogo> https://github.com/bitcoin/bitcoin/blob/freenode-verf/contrib/freenode.verf
398 2013-06-30 18:10:34 <nanotube> michagogo: yes we are group registered.
399 2013-06-30 18:11:15 <michagogo> Hmm, so why don't we do cloaks?
400 2013-06-30 18:12:10 <nsh> that's actually a good idea
401 2013-06-30 18:12:17 <nsh> considering how people in #bitcoin are targets for hacks
402 2013-06-30 18:12:29 <nsh> having IPs on show should be discouraged
403 2013-06-30 18:12:45 <michagogo> nsh: That's not what cloaks are primarily for
404 2013-06-30 18:13:12 <nsh> ACTION gestures equivocation
405 2013-06-30 18:13:17 <michagogo> And if that's what you're using a cloak for, unless you use SASL configured to fail a connection if SASL fails it's likely to not protect you
406 2013-06-30 18:13:32 <michagogo> All it really takes is a MONITOR on your nick
407 2013-06-30 18:13:42 <pierre`> having secure desktops is a better idea.
408 2013-06-30 18:13:44 <nsh> true
409 2013-06-30 18:14:21 <michagogo> ACTION pings nanotube again
410 2013-06-30 18:15:26 <nanotube> michagogo: because someone would have to manually deal with every. single. one.
411 2013-06-30 18:15:42 <michagogo> nanotube: Not some*one*, if I'm not mistaken
412 2013-06-30 18:15:52 <michagogo> You can delegate that out to multiple contacts, AFAIK
413 2013-06-30 18:16:16 <nanotube> sure, it's just been deemed irrelevant so nobody cared to deal with it.
414 2013-06-30 18:16:26 <michagogo> Not to mention, it's not like you'd hand them out to anyone and everyone who asks (that's not what group cloaks are designed for anyway)
415 2013-06-30 18:22:40 <TheLordOfTime> michagogo:  ehh...
416 2013-06-30 18:22:59 <TheLordOfTime> michagogo:  it's a tad hard, now... with GRFs disabled alternate group contacts can't as easily register for that ability
417 2013-06-30 18:23:04 <TheLordOfTime> i ran into that with my GRF on TrekWeb
418 2013-06-30 18:23:46 <michagogo> TheLordOfTime: It's not just a matter of the GC saying to staff "please let x y and z request group cloaks"?
419 2013-06-30 18:23:58 <TheLordOfTime> michagogo:  consider several things:
420 2013-06-30 18:24:05 <TheLordOfTime> (1) a group cloak shows affiliation in some way with that group
421 2013-06-30 18:24:21 <michagogo> TheLordOfTime: Right.
422 2013-06-30 18:24:27 <michagogo> [23:13:08] <michagogo> Not to mention, it's not like you'd hand them out to anyone and everyone who asks
423 2013-06-30 18:24:38 <TheLordOfTime> (2) how do we determine "what determines affiliation?"
424 2013-06-30 18:24:48 <TheLordOfTime> if we go specifically with people involved in the bitcion foundation that's easy
425 2013-06-30 18:24:56 <TheLordOfTime> if we branch out to contributing devs that can be trickier
426 2013-06-30 18:25:02 <TheLordOfTime> any further and it's weird
427 2013-06-30 18:25:23 <TheLordOfTime> (3) the GC and ops of #bitcoin might have to contend with everyone wanting to ask for a cloak once a handful get bitcoin/ cloaks
428 2013-06-30 18:25:49 <TheLordOfTime> and (4) it causes a lot of chaos sometimes
429 2013-06-30 18:26:06 <TheLordOfTime> TBH, i don't see a need for every group to use cloaks
430 2013-06-30 18:26:12 <michagogo> TheLordOfTime: Well, for example, the various Wikimedia projects have policies defining to what extent you need to be active within the projects to be eligible
431 2013-06-30 18:26:15 <TheLordOfTime> i assume nanotube will agree on that one
432 2013-06-30 18:26:26 <TheLordOfTime> (on point 4 and my TBH opinion)
433 2013-06-30 18:26:42 <TheLordOfTime> michagogo:  but who defines the policies for a bitcoin/ cloak?
434 2013-06-30 18:26:57 <michagogo> TheLordOfTime: Well, ultimately whoever the GC is
435 2013-06-30 18:26:57 <TheLordOfTime> ideally whoever is in charge of the bitcoin group, but then again, what do they define the policy to be?
436 2013-06-30 18:27:11 <TheLordOfTime> what determines "contribution" or "Inclusion" or "eligibility"
437 2013-06-30 18:27:28 <michagogo> Up to the GC and whoever s/he decides to take input from.
438 2013-06-30 18:27:47 <TheLordOfTime> michagogo:  then us giving opinions as mere mortals in comparision is irrelevant.
439 2013-06-30 18:28:07 <TheLordOfTime> and we go back to square one: If they want to give cloaks that's their choice and our opinions shouldn't influence it :)
440 2013-06-30 18:28:17 <michagogo> I didn't say that.
441 2013-06-30 18:28:21 <michagogo> (the second part, I mean)
442 2013-06-30 18:28:32 <TheLordOfTime> but that's ultimately still square one whether we say it or not :p
443 2013-06-30 18:28:47 <TheLordOfTime> *sigh* i hate people sometimes...
444 2013-06-30 18:28:55 <TheLordOfTime> time to go yell at someone for breaking a server
445 2013-06-30 18:29:02 <michagogo> Ouch,
446 2013-06-30 18:29:04 <michagogo> What server?
447 2013-06-30 18:32:48 <TheLordOfTime> michagogo:  one of the dedicateds i manage for them
448 2013-06-30 18:33:03 <michagogo> Ah, hosting or something?
449 2013-06-30 18:33:05 <TheLordOfTime> newbie admin, they accidentally triggered a kernel panic
450 2013-06-30 18:33:07 <michagogo> How'd they break it?
451 2013-06-30 18:33:16 <TheLordOfTime> no, they pay for colo, i'm a hired tech for them, on call when they break something
452 2013-06-30 18:33:30 <TheLordOfTime> i dunno i have to go on site at a data center to fix it
453 2013-06-30 18:33:38 <michagogo> Ah
454 2013-06-30 18:33:45 <TheLordOfTime> but apparently they triggered a kernel panic
455 2013-06-30 18:33:53 <TheLordOfTime> from what they said, anyways
456 2013-06-30 18:33:55 <TheLordOfTime> ACTION shrugs
457 2013-06-30 18:34:01 <michagogo> So it's not like a hosting thing where you can push a button and restore a vanilla image?
458 2013-06-30 18:34:07 <TheLordOfTime> i make $250 per call, so i can understand why they hire other techs.
459 2013-06-30 18:34:22 <TheLordOfTime> nope, it's their server, i'm the on-call guy though for when their people screw up
460 2013-06-30 18:34:32 <TheLordOfTime> and it's not a VM so i can't restart the image
461 2013-06-30 18:34:40 <TheLordOfTime> because there is no image
462 2013-06-30 18:35:02 <michagogo> Right.
463 2013-06-30 18:35:06 <TheLordOfTime> this has happened before, usually i just reboot the server and chastise whoever broke it
464 2013-06-30 18:35:12 <TheLordOfTime> and i make $250 xD
465 2013-06-30 18:36:01 <michagogo> y u no install remotely-managed outlet
466 2013-06-30 18:36:48 <michagogo> That way if it just needs a reboot you push a button from home
467 2013-06-30 18:37:02 <TheLordOfTime> michagogo:  i keep wanting to do that, but...
468 2013-06-30 18:37:12 <TheLordOfTime> anyways back in a few... it's a 5 minute drive to the datacenter
469 2013-06-30 18:37:15 <michagogo> Ah
470 2013-06-30 18:37:21 <michagogo> Didn't realize you were so close
471 2013-06-30 19:57:23 <TheUni> sipa / warren: ping
472 2013-06-30 20:00:28 <starsoccer> hey quick question here, so I understand when ever you send bitcoins it is breaking down a prevoius transaction. so if I send someone 5btc its really lets say sending 10btc 5 to person A and then 5 to another address it generates. My question is why cant each address just have 2 addresses. so for instance. address 1abc and adress 1abcd. when I send on 1abc the leftover is put to 1abcd.
473 2013-06-30 20:00:28 <starsoccer> then after sending again it moves the extra back to 1abc
474 2013-06-30 20:01:06 <warren> TheUni: hey
475 2013-06-30 20:01:43 <TheUni> warren: been a while. I'm about to push my refactored autotools out finally, any chance I could get you to try the linux gitian build?
476 2013-06-30 20:02:19 <warren> TheUni: sure. just give me the URL and branch
477 2013-06-30 20:02:37 <warren> TheUni: btw can't you setup virtualbox gitian on your mac?
478 2013-06-30 20:02:59 <TheUni> warren: ok. i'm tracking down a packaging bug, but I'll go ahead and push what i've got. I'll force-push once i get it fixed up
479 2013-06-30 20:03:05 <BTCOxygen> starsoccer: Thats called change address.
480 2013-06-30 20:03:16 <BTCOxygen> starsoccer: Its implemented to increase the privacy of users.
481 2013-06-30 20:03:27 <starsoccer> i disagree it should be an option tho
482 2013-06-30 20:03:29 <TheUni> warren: as long as there's someone around here that doesn't mind testing, I'm not going to mess with it. I know it'll just infurate me
483 2013-06-30 20:03:41 <TheUni> *infuriate
484 2013-06-30 20:03:46 <starsoccer> I find it annoying that I have to backup every single time i do a transaction because of it
485 2013-06-30 20:04:11 <BTCOxygen> starsoccer: You don't need to backup everytime you do a transaction.
486 2013-06-30 20:04:30 <xenland> starsoccer weeeee
487 2013-06-30 20:04:47 <starsoccer> BTC0xygen yea you do
488 2013-06-30 20:04:48 <warren> TheUni: it really shouldn't be difficult to setup
489 2013-06-30 20:04:57 <warren> TheUni: it's already ported
490 2013-06-30 20:05:05 <starsoccer> BTCOxygen why are there 2 of you?
491 2013-06-30 20:05:08 <xenland> starsoccer you only backup your wallet every new address generation.
492 2013-06-30 20:05:12 <starsoccer> xenland lol
493 2013-06-30 20:05:18 <xenland> :)
494 2013-06-30 20:05:20 <starsoccer> xenland really
495 2013-06-30 20:05:22 <warren> TheUni: plus, you want to be sure your gitiian build is equal to other's builds
496 2013-06-30 20:05:29 <starsoccer> someone told me every transaction
497 2013-06-30 20:05:32 <s17> help, please. i imported a private key with pywallet.py, but forgot the "reserve" flag, so the address went into the address book, then i tried again and it went to "receive addresses", but when i export privkeys, the key does not generate the same address
498 2013-06-30 20:05:35 <BTCOxygen> starsoccer: What xenland said.
499 2013-06-30 20:05:47 <s17> is there any way to recover from this?
500 2013-06-30 20:05:59 <TheUni> warren: i suppose that one's a valid point
501 2013-06-30 20:06:28 <xenland> Unless every tx you do involves a new address then your statement would be accurate in the context of "backup" efificenticy to time wasted ratio.
502 2013-06-30 20:06:40 <BTCOxygen> starsoccer: hmm, My clone, anyway, Its off-topic on #bitcoin-dev
503 2013-06-30 20:06:42 <xenland> (I'm a horrible speller everyone just calm down)
504 2013-06-30 20:06:48 <starsoccer> so right now I have i think 5 addresses i use