1 2014-04-15 02:47:51 <GAit> How do you envision people being able to send funds to known others without reusing addresses?  The logistic of obtaining new unique address and the compromises in terms of privacy/decentralization
  2 2014-04-15 02:49:12 <warren> Given a git annotated tag (-a or -s), is there a command that will give you the git hash of the commit that was taggeD?
  3 2014-04-15 02:50:32 <gmaxwell> GAit: (1) improve those logistics, for reoccuring payments (2) start giving people extended public keys so they can generate more addresses on their own.
  4 2014-04-15 02:51:55 <GAit> gmaxwell: if people have my master public, how do i know which addresses they have generated, can it be done in a distributed fashion without having to ask them for their unique branch?
  5 2014-04-15 02:52:02 <gmaxwell> there is a (3) for broadcast payments (e.g. anonymous donations where there is no two way communication) there is a technique where people can generate new addresses for you which are only distinguishable as yours by you... but it has some challenges. (scanning for payments is computaitonally expensive)
  6 2014-04-15 02:52:28 <warren> The best I can figure out is git rev-parse HEAD^ == git rev-parse TAGNAME^ (the hash of the commit before both HEAD and TAGNAME is equal).  but I can't find a command that outputs the commit that was tagged.
  7 2014-04-15 02:53:00 <gmaxwell> GAit: you always give them a branch, and they they generate more for you, in order.  And you just scan a limited depth forward. If they go and jump a billion addresses down the chain, well, thats their own problem, as far as you're concerned they haven't paid you.
  8 2014-04-15 02:53:44 <GAit> isn't generating a branch for them as much work as generating addresses for everyone in terms of protocol, even if more efficent I guess?
  9 2014-04-15 02:55:40 <gmaxwell> I don't follow what you're saying.  This lets you give someone one piece of information and they can pay you repeadily without reusing addresses, thats all.
 10 2014-04-15 02:56:58 <gmaxwell> it does not address broadcast acceptance, but broadcast acceptance is actually a very specialized case which has a bunch of considerations.  E.g. say you use a single static address that you announce and people send you funds without communicating.  I see someone sent you some funds, so then I rush over to you and say "see, I paid you for that car you were selling, hand it over"
 11 2014-04-15 02:57:10 <GAit> gmaxwell: sorry I wasn't clear. I'm just thinking outloud that if I want people to be able to find me and pay me via some directory that provides branches having this directory privde directly new addresses doesn't seem a massive different from a business result point of view, of course giving out branches is more efficent and requires less server requests
 12 2014-04-15 02:58:12 <GAit> and either way the server knows about all addresses
 13 2014-04-15 02:59:48 <gmaxwell> well it's perhaps partially a UI issue, really what giving someone a branch says is "you can pay me multiple times and I'll do something sensible" where as there is really no promise for reuse with an address. With an address maybe its swept right away and the private key is destroyed.
 14 2014-04-15 03:00:33 <gmaxwell> in some cases you may want a party to make reoccuring payments to you, a popular example is a mining pool.  For security reasons some mining pools will lock an address to an account... but using a single address forces them to reuse. Better to give them a branch.
 15 2014-04-15 03:00:44 <GAit> assuming the UI would either way create or use a new address this is a technical point not an UI anymore right?
 16 2014-04-15 03:02:22 <GAit> can't there be a federated system maybe built on top of xmpp or something that provides new addresses as requested based on some signed detail ( i was reading about email signature DKIM with webfist)
 17 2014-04-15 03:03:02 <GAit> or is giving out master and branches the best solution?
 18 2014-04-15 03:04:39 <gmaxwell> GAit: it could but then you have to make a connection out whenever you want to pay, and now the user is dependant on an always online service to give out addresses for it.
 19 2014-04-15 03:05:32 <gmaxwell> if I tell some mining pool person that he has to connect out to a server to fetch an address his response might be instead to just only support static addresses. :( because of crap like the server is down and now you have to gracefully handle the timeouts.
 20 2014-04-15 03:05:49 <GAit> both system can co exists but yeah sounds like branch would handle much better network issues
 21 2014-04-15 03:06:38 <GAit> maybe there is some distributed yet private solution
 22 2014-04-15 03:07:10 <GAit> and redandant
 23 2014-04-15 03:07:13 <GAit> oh yeah webfist is redundant
 24 2014-04-15 03:08:07 <GAit> but how do you deal with the branches without centralization and without requiring people to send you the branch
 25 2014-04-15 03:08:12 <GAit> and without losing on privacy all over
 26 2014-04-15 03:12:06 <GAit> gmaxwell: what if the branches are random and kept encrypted on the blockchain as OP_RETURN <data> ?
 27 2014-04-15 03:14:23 <GAit> I'm not sure it's a good idea to store data on the blockchain but i saw the functionality added and i wondered while thinking :)
 28 2014-04-15 03:15:30 <gmaxwell> GAit: doesn't make any sense.
 29 2014-04-15 03:18:17 <GAit> i'm sure i skipped a lot of steps: webfist if i understood correctly allows anyone to use independently verify that an email came from you. In this way you can easily publish a master public,  which is kept encrypted on various distributed servers, if i understood correctly it is kept encrypted by email address so that anyone that has it can ask for it but the servers can't read them.
 30 2014-04-15 03:19:17 <GAit> So i can find one of these distributed servers, ask for some hash i guess of email x@z.k, get this blob, decrypt it, read master and verify email was signed by google and push a new random branch into the blockchain encrypted with your public key such that you can scan the blockchain and find them all and decrypt them only yourself
 31 2014-04-15 03:22:53 <GAit> Does it make less sense than before? :)
 32 2014-04-15 03:45:31 <warren> git rev-list -1 TAGNAME
 33 2014-04-15 04:02:58 <warren> two of my testnet nodes are stuck on block 224679
 34 2014-04-15 04:19:22 <ajwja> hey folks.  are they any docs out there that talk about how to run the tests in qa/rpc-tests?
 35 2014-04-15 05:28:02 <warren> hno: you still have your blocks, index and chainstate from the time your testnet node failed recently?
 36 2014-04-15 06:02:41 <megaworm> I am starting a new pool similar to blackcoinpool.com.  I am looking for experienced pool operators who would like to partner with me.  I am a designer/frontend developer with experience in branding and marketing.  Please contact me via PM or email wearesatoshifoundation@gmail.com for more details.
 37 2014-04-15 06:23:25 <hno> warren, maybe.
 38 2014-04-15 06:24:11 <hno> in that aI do have a copy, but about the same time the node did realize it was down a long stale fork.
 39 2014-04-15 06:24:38 <hno> didn't seem to recover however.
 40 2014-04-15 07:35:47 <warren> wumpus: there's a drawback to getting version from configure.ac instead of the previous tag
 41 2014-04-15 07:36:14 <warren> wumpus: that long string built from previous tag, count of commits and short hash actually was a valid git identifier before.
 42 2014-04-15 07:36:26 <wumpus> warren: not worth worrying about, the definitive version info should be only in one place
 43 2014-04-15 07:36:47 <wumpus> (and making configure.ac that place makes sense because it already works, also without git)
 44 2014-04-15 07:37:08 <wumpus> well if you include the git hash, that's a valid identifier too
 45 2014-04-15 07:37:17 <warren> okay.  I'm removing "g" as a prefix from the fake short hash because it isn't a valid git identifier anymore.
 46 2014-04-15 07:37:24 <splitting> im having some trouble using bitcoin and python
 47 2014-04-15 07:37:34 <splitting> trying to make an api call to the bitcoin daemon
 48 2014-04-15 07:37:40 <splitting> but i keep getting connection refused
 49 2014-04-15 07:37:43 <wumpus> okay then you need to copy part of the thing instead of the whole thing but that's a small inconvenience
 50 2014-04-15 07:37:54 <wumpus> I've always found the 'g' prefix strange
 51 2014-04-15 07:38:52 <splitting> wumpus, i remember you from yesterday or the day before
 52 2014-04-15 07:42:16 <wumpus> splitting: if you get connection refused there can really be only one reason, it is not bound to that port
 53 2014-04-15 07:42:30 <wumpus> splitting: try netstat -anp to see what ports the daemon is bound to
 54 2014-04-15 07:43:05 <hno> splitting, is the daemon listening?
 55 2014-04-15 07:43:12 <splitting> hold on
 56 2014-04-15 07:43:34 <splitting> i have rpcport=8332 in my bitcoin.conf
 57 2014-04-15 07:43:38 <splitting> and im checking now
 58 2014-04-15 07:43:59 <hno> splitting, what address are you trying to connect to?
 59 2014-04-15 07:44:08 <splitting> localhost
 60 2014-04-15 07:44:16 <splitting> 127.0.0.1
 61 2014-04-15 07:44:22 <hno> should work.
 62 2014-04-15 07:45:06 <sipa> splitting: on localhost, or remotely?
 63 2014-04-15 07:45:15 <splitting> on localhost
 64 2014-04-15 07:47:10 <warren> hno: what version of bitcoin were you using when testnet got stuck?
 65 2014-04-15 07:47:41 <splitting> self.walletProxy = ServiceProxy(http://user:pass@127.0.0.1:8332)
 66 2014-04-15 07:49:17 <splitting> any ideas?
 67 2014-04-15 07:49:31 <wumpus> what if you poke the port with nc or telnet?
 68 2014-04-15 07:54:16 <splitting> nvm got it
 69 2014-04-15 07:58:35 <warren> hno: did your testnet sync fix on restart or if you downgrade to 0.9.0 or 0.9.1?
 70 2014-04-15 08:55:56 <warren> http://nightly.bitcoin.it/
 71 2014-04-15 08:56:03 <warren> https://github.com/nightlybitcoin/bitcoin/commits/0.9.99.0-20140415-74dd52a
 72 2014-04-15 08:56:11 <warren> reproducible builds from the matching tag
 73 2014-04-15 10:06:10 <warren> https://bitcointalk.org/index.php?topic=571414  Unofficial nightly builds
 74 2014-04-15 10:07:18 <hno> warren, I deleted testnet3 and let the note resync from start. I do have a backup of the old testnet3 folder but have not yet verified that the problem got captured.
 75 2014-04-15 10:08:55 <hno> the node was running 0.8.6 at the time, and restart or upgrade to 0.9.0 did not help.
 76 2014-04-15 10:12:20 <warren> hno: thanks, that's very helpful to know
 77 2014-04-15 10:12:25 <warren> wumpus: ^^
 78 2014-04-15 10:12:44 <warren> hno: at the point where it got stuck, did you see incoming orphaned blocks after it?
 79 2014-04-15 10:17:21 <jtimon> also tried without user:pass
 80 2014-04-15 10:17:21 <jtimon> any ideas? what am I doing wrong?
 81 2014-04-15 10:17:21 <jtimon> mhhm, ./src/bitcoind and curl -H "Content-Type: application/json" -X POST -d '{"method":"getinfo"}' http://user:password@127.0.0.1:8332
 82 2014-04-15 10:17:21 <jtimon> works just fine, but I'm not able to do the same with bitcoind -regtest and curl -H "Content-Type: application/json" -X POST -d '{"method":"getinfo"}' http://user:password@127.0.0.1:18444
 83 2014-04-15 10:18:39 <warren> I know for a fact that regtest RPC works.
 84 2014-04-15 10:19:36 <hno> warren, just when I made a backup it gave a "long fork detected" message, indicating the block it was stuck on and the then current block.
 85 2014-04-15 10:22:06 <nederhoed> Hi there, we discussed yesterday about bitcoin PPA for Ubuntu Saucy i386 that failed. Is there any news about restarting the build process, for example?
 86 2014-04-15 10:23:18 <jtimon> thank you warren I must be doing something wrong, I'm getting "curl: (52) Empty reply from server" also tried deleting the regtest folder...
 87 2014-04-15 10:32:07 <sipa> jtimon: does it work when you try through bitcoin-cli?
 88 2014-04-15 10:33:32 <jtimon> sipa, yep, "bitcoin-cli -regtest getinfo" works fine as well
 89 2014-04-15 10:34:50 <jtimon> but I want to make http calls from python after I get it to work with curl
 90 2014-04-15 10:45:29 <random_cat_> re: Why are we bleeding nodes?:  my personal experience agrees with ffj -- RAM is the key factor.  I can no longer run a node in AWS EC2 micro unless dedicated to node.  node must run swap.  this seems silly, but i haven't the cycles to investigate
 91 2014-04-15 10:46:23 <sipa> how much ram does a micro instance have?
 92 2014-04-15 10:46:32 <random_cat_> 600K
 93 2014-04-15 10:46:56 <sipa> M, i hope?
 94 2014-04-15 10:46:56 <warren> K?
 95 2014-04-15 10:49:07 <warren> It's below the 640K memory limit set by Gates. =P
 96 2014-04-15 10:49:22 <random_cat_> yes, M.  my 'small system' fingers typed the wrong prefix
 97 2014-04-15 11:45:17 <vetch> random_cat_: are you disabling the wallet? that saves some memory.
 98 2014-04-15 13:42:41 <AmThatsMe> Hi everyone !
 99 2014-04-15 13:44:05 <AmThatsMe> how should i approach testing network communication between nodes ? lets say i added changed the processing of a the "inv" message. how should i debug it ?
100 2014-04-15 13:49:09 <sipa> if it interferes with block validation/propagation/convergence, matt's comparison tool will likely catch it
101 2014-04-15 13:51:28 <AmThatsMe> sipa: that was for me ?
102 2014-04-15 13:51:34 <sipa> yes
103 2014-04-15 13:55:26 <AmThatsMe> sipa: i meant in a more general sense, debugging network message processing. Lets say i added a new message, how can i check that my code works ? start some nodes on the test net and start sending messages between them ? or there is a better way?
104 2014-04-15 13:57:02 <sipa> AmThatsMe: that depends on what kind of message it is, but yes
105 2014-04-15 14:01:33 <AmThatsMe> sipa: i want to play with auto checkpoint sync (implemented in aurora coin), for that i need to add a new message, i.e, "checkpoint". Should i debug it just by starting 2 nodes and sending the message from one to the other ?
106 2014-04-15 14:02:05 <Luke-Jr> AmThatsMe: this is #bitcoin-dev , for BITCOIN development.
107 2014-04-15 14:02:07 <sipa> AmThatsMe: i just threw up a little
108 2014-04-15 14:02:16 <Luke-Jr> sipa: >_<
109 2014-04-15 14:02:18 <sipa> AmThatsMe: please do not ever suggest something so centralizing here
110 2014-04-15 14:03:14 <sipa> (we want to get rid of checkpoints entire, among other reasons because it incorrectly makes people think it improves security)
111 2014-04-15 14:03:18 <sipa> *entirely
112 2014-04-15 14:05:34 <AmThatsMe> sorry !! :) ... thats why i said "play with", just because i saw the code and it is already implemented. I am not suggesting its an improvement, just my way of learning better the code.
113 2014-04-15 14:06:24 <sipa> well, a change like that is very tricky, as it changes the consensus model
114 2014-04-15 14:06:44 <sipa> not simply a change to the p2p protocol
115 2014-04-15 14:06:45 <AmThatsMe> Just want to understand better how network debugging is done on the testnet
116 2014-04-15 14:07:04 <sipa> to compare: the adding of the ping/pong message at no point threatened network consensus
117 2014-04-15 14:07:21 <sipa> it's purely something that affects the communication between two specific peers
118 2014-04-15 14:08:05 <AmThatsMe> It's a pure technical attempt to understand better how things work. If it makes any difference, lets say i want to add Ping2 message
119 2014-04-15 14:08:15 <sipa> ok
120 2014-04-15 14:08:38 <sipa> things like -debug=net will help
121 2014-04-15 14:08:48 <sipa> and testnet-in-a-box
122 2014-04-15 14:09:06 <sipa> i believe there's a wireshark decoder module for bitcoin
123 2014-04-15 14:11:10 <sipa> implementing the change in other p2p implementations (there's a python node implementation, for example) may help as well
124 2014-04-15 14:14:04 <AmThatsMe> sipa: thanks for the help !! sorry if i made a newbie impression, but hi, i'm a newbie :)
125 2014-04-15 14:21:06 <GAit> sipa: do you know much about webfist & webfinger?
126 2014-04-15 14:22:31 <sipa> GAit: never heard of those
127 2014-04-15 14:23:39 <GAit> WebFist uses DKIM-signed email to prove you are the owner of an email and then uses some decentralized system to keep whatever you published encrypted and available by some token hash(like your email)
128 2014-04-15 14:24:01 <GAit> could be used to publish a master public for bip0032
129 2014-04-15 14:24:43 <sipa> that's just as bad as publishing a single address
130 2014-04-15 14:25:02 <sipa> as others can still identify all your transactions
131 2014-04-15 14:25:15 <GAit> not really, they need to know the branch used
132 2014-04-15 14:25:30 <GAit> and as far as i know you can use gaps in a distributed manner without risking to reuse addresses
133 2014-04-15 14:25:39 <sipa> that's very very little entropy, and not intended to be secure
134 2014-04-15 14:25:41 <GAit> can't*
135 2014-04-15 14:25:49 <sipa> seriously, don't share your address with the world
136 2014-04-15 14:26:00 <sipa> whether that address is a single key, or a master public key
137 2014-04-15 14:26:29 <GAit> maybe i'm confused but if the branch has enough entropy isn't this the same as BIP0032 private derivation?
138 2014-04-15 14:26:34 <sipa> you seem to misunderstand why "reuse" it bad... because it allows linking your transactions together
139 2014-04-15 14:26:53 <sipa> if you publish your entire public master, that is hardly made any more difficulty
140 2014-04-15 14:28:14 <sipa> by entropy here i mean the amount of information another needs to guess to see transactions link together
141 2014-04-15 14:28:31 <sipa> that's just branch numbers and key numbers beneath it... at most a few bits of data
142 2014-04-15 14:28:39 <GAit> if the branch path is say 128 bits, how can you correlate?
143 2014-04-15 14:29:13 <sipa> not, but why do you want branches of 128 bits? the receiver will never detect those
144 2014-04-15 14:29:20 <sipa> unless you tell them which branch to use
145 2014-04-15 14:29:22 <GAit> well, let me get there
146 2014-04-15 14:29:36 <sipa> in which case you're much better off using the payment protocol, with a signed identity
147 2014-04-15 14:29:45 <sipa> instead of trying to use the public master key as an identity
148 2014-04-15 14:30:23 <GAit> the payment protocol requires some service to be up, as far as I know it wouldn't be distributed
149 2014-04-15 14:30:28 <GAit> anyway, my next point was going to be
150 2014-04-15 14:30:29 <sipa> yes
151 2014-04-15 14:30:45 <sipa> you need someone to be 'up' if you need to tell them or ask them which branch to use!
152 2014-04-15 14:31:04 <GAit> what if the user has this public master, generates a random branch with enough entropy and then encrypts it with your public and puts in the blockchain as prunable data. It may be a bad idea but for the sake of curiousity i would like to discuss it
153 2014-04-15 14:31:20 <sipa> don't use the blockchain for private data communication
154 2014-04-15 14:31:24 <sipa> there's no point
155 2014-04-15 14:31:46 <sipa> you're basically reinventing stealth addresses
156 2014-04-15 14:31:57 <sipa> which also require out-of-band communication
157 2014-04-15 14:31:58 <GAit> oh, i didn't study those yet
158 2014-04-15 14:32:05 <sipa> and they're incompatible with SPV
159 2014-04-15 14:32:39 <sipa> imho, it's a slightly regrettable but inevitability that people will use third party services to receive coins anyway
160 2014-04-15 14:32:56 <sipa> which simplifies technicalities so much
161 2014-04-15 14:33:52 <sipa> (you can just use a url to pay, you have instant support for refunds/memo's/comments, you don't spam the blockchain, you don't need to scan for transactions, and except for the coin-accepting service you have perfect privacy)
162 2014-04-15 14:34:21 <GAit> yeah that's how we implemented the donation buttons, generate a new P2SH with new keys in the 2of2, but i can't stop thinking of a way to make it secure, private and distributed so we don't have to have our own thing
163 2014-04-15 14:34:23 <vetch> sipa: didn't gmaxwell have a way of getting around that? "bloom bait" I think it was called
164 2014-04-15 14:34:48 <GAit> sipa: urls is fine but i have to be around to give it to yuou
165 2014-04-15 14:34:55 <GAit> or have some third party handle that for me
166 2014-04-15 14:36:07 <sipa> vetch: just compromising privacy somewhat and making it equally less expensive for SPV (afaik, i'll let him comment to be sure)
167 2014-04-15 14:37:10 <GAit> anyway, should there be a standard ways for these coin-accepting third parties to give out addresses?
168 2014-04-15 14:37:49 <GAit> assuming they are the compromise and you don't give our your master public (which was what gmaxwell was suggesting yesterday)
169 2014-04-15 14:39:09 <Luke-Jr> GAit: addresses are basically deprecated by the payment protocol ;)
170 2014-04-15 14:39:52 <sipa> GAit: we need some delegation support in the payment protocol for that (i believe mike was working on that), so the third party knows a chain extended public key to give out keys, and signs them with a certificate issued by the owner of the chain that they're authoritzed to do so
171 2014-04-15 14:39:58 <Luke-Jr> should be able to generate payment requests as a file
172 2014-04-15 14:40:56 <GAit> sipa: that's nice to know. So I guess the 'payment protocol' won't be used for commercial payments only but in general between parties as mean to exchange btc like we do today with addresses?
173 2014-04-15 14:41:13 <sipa> GAit: that is certainly my hope, but we're a long way from that
174 2014-04-15 14:41:19 <Michail1> Strange.  I get to work.  Fire up the computers.  3 of them that have the bitcoin-qt client on them are stated an error.  I said ok, nothing loading.  Trying to Fire back up and get....  Error opening block database.  Do you want to rebuild the block database now?     I could understand one computer, but all three?
175 2014-04-15 14:41:21 <sipa> i'd certainly like to see people help pushing for that
176 2014-04-15 14:41:37 <sipa> Michail1: which version?
177 2014-04-15 14:41:40 <Michail1> 8.6
178 2014-04-15 14:41:49 <vetch> Michail1: did you copy the databases while they were running?
179 2014-04-15 14:41:55 <Luke-Jr> Michail1: did you ever run 0.9?
180 2014-04-15 14:41:55 <Michail1> nope.
181 2014-04-15 14:42:03 <Luke-Jr> also, 0.8.6 is not 8.6
182 2014-04-15 14:42:29 <Michail1> Luke-Jr - I ran .9 on my laptop for about 5 mins a couple of weeks ago.  Didn't like it and reverted.  However, the other 2 computers have never seen .9
183 2014-04-15 14:42:40 <sipa> strange
184 2014-04-15 14:42:50 <Luke-Jr> Michail1: 0.9 release notes did make it clear that you can't just revert :p
185 2014-04-15 14:43:01 <sipa> what did you not like about 0.9?
186 2014-04-15 14:43:04 <Michail1> Understood.  would explain 1 computer, but all three?
187 2014-04-15 14:43:12 <sipa> yeah, i can't explain that
188 2014-04-15 14:43:19 <Luke-Jr> solar flare targetted you? <.<
189 2014-04-15 14:43:20 <Michail1> sipa - Ohhhh, I posted many reasons why I didnt like 9.
190 2014-04-15 14:43:30 <Michail1> Luke-Jr - Maybe, the blood moon got me.
191 2014-04-15 14:43:51 <Luke-Jr> I don't think the moon can cause things like this..
192 2014-04-15 14:43:52 <vetch> what's not to "like" about 0.9? there's really no visible differences
193 2014-04-15 14:43:58 <Michail1> bitcoin was running fine on laptop until I got to work.
194 2014-04-15 14:43:59 <Luke-Jr> vetch: there sure are
195 2014-04-15 14:44:07 <Michail1> vetch - looks again.
196 2014-04-15 14:44:12 <Luke-Jr> Michail1: do you have antivirus software?
197 2014-04-15 14:44:14 <Michail1> "look"
198 2014-04-15 14:44:31 <vetch> oh you mean with the GUI?
199 2014-04-15 14:44:36 <Michail1> Luke-Jr - yes.   norton 360 on laptop.   corp edition norton on work computers.
200 2014-04-15 14:44:46 <Luke-Jr> vetch: … only the GUI has visible looks :P
201 2014-04-15 14:44:49 <Michail1> vetch - Well, you said "visible"
202 2014-04-15 14:44:54 <Luke-Jr> Michail1: it probably deleted the index
203 2014-04-15 14:45:03 <vetch> "tangible" differences then.
204 2014-04-15 14:45:06 <Michail1> Luke-Jr - On all three computers?    checking
205 2014-04-15 14:45:12 <Luke-Jr> Michail1: it's the same AV software..
206 2014-04-15 14:45:23 <Luke-Jr> Michail1: to clarify, it probably deleted *parts* of the index
207 2014-04-15 14:46:03 <Apocalyptic> <Luke-Jr> I don't think the moon can cause things like this.. << the moon can do powerfull things
208 2014-04-15 14:46:03 <vetch> Michail1: someone stuffed some strings that antivirus uses for detection in the blcokchain. the blocks themselves are ignored because the virus suites don't like large files. the indexes are small enough for them to scan and delete.
209 2014-04-15 14:46:31 <Michail1> norton notifies if there is an issue.  nothing in quarentine.
210 2014-04-15 14:46:38 <Michail1> all block files are there.
211 2014-04-15 14:46:46 <vetch> indexes are the issue
212 2014-04-15 14:47:12 <Michail1> last 132 touched 15 mins ago.
213 2014-04-15 14:47:37 <Michail1> Saw that it wanted to rebuild.   logged into work computer, started bitcoin client, and same thing.
214 2014-04-15 14:48:09 <vetch> do you live near a train station?
215 2014-04-15 14:48:10 <Michail1> Rebuild is complete from scratch or just reindex?
216 2014-04-15 14:48:14 <Michail1> no
217 2014-04-15 14:51:28 <GAit> thanks sipa Luke-Jr and vetch for the discussion/input
218 2014-04-15 14:52:50 <vetch> Michail1: here's a good article to read while your nodes rebuild, it's sort of related http://jakepoz.com/soviet_debugging.html
219 2014-04-15 14:52:54 <Michail1> reindexing block on disk....   272 weeks behind.  uhhg
220 2014-04-15 14:54:07 <sipa> vetch: not the indexes, just the chainstate
221 2014-04-15 14:54:17 <sipa> (which is a database, but not an index)
222 2014-04-15 14:54:40 <vetch> sipa: noted
223 2014-04-15 14:58:37 <Michail1> 943652.sst (Silly.218) detected by Auto-Protect
224 2014-04-15 14:59:00 <Luke-Jr> yep
225 2014-04-15 14:59:24 <Michail1> gonna really suck if people have to start disabling virus protection to even run the bitcoin client.
226 2014-04-15 15:01:30 <Michail1> 4/15/2014 7:28:12 AM,High,943652.sst (Silly.218) detected by Auto-Protect,Blocked,Resolved - No Action Required,
227 2014-04-15 15:01:30 <Michail1> Category: Resolved Security Risks
228 2014-04-15 15:01:30 <Michail1> Date & Time,Risk,Activity,Status,Recommended Action,Path - Filename
229 2014-04-15 15:01:46 <Luke-Jr> Michail1: want to make the patch to workaround it? :P
230 2014-04-15 15:02:23 <Michail1> Sure.  Teach me.    Actually, I feel it is better to tell the smart people in here, since I suspect you will hear more about it later.
231 2014-04-15 15:02:40 <Luke-Jr> it's kinda a n00b-dev task
232 2014-04-15 15:02:56 <Luke-Jr> basically the idea is to just encrypt everything in the blockchain/indexes when writing them to disk
233 2014-04-15 15:03:00 <Michail1> Norton updated 5 mins before the issue.   So, it will popup with the issue from more people shortly.
234 2014-04-15 15:03:07 <Michail1> Ahhh, but I am not a dev.
235 2014-04-15 15:03:15 <Luke-Jr> also, complain to Norton ;)
236 2014-04-15 15:03:26 <Michail1> I complain to them enough.  :)
237 2014-04-15 15:04:06 <Michail1> So, I did my part in notifying you about an issue, and figured out what caused the issue.  Your turn to fix it.  :D
238 2014-04-15 15:07:06 <Luke-Jr> Michail1: this is a Norton bug, it's their turn to fix it.
239 2014-04-15 15:07:19 <Luke-Jr> a workaround on Bitcoin Core's end would be handy, but nobody's duty.
240 2014-04-15 15:07:33 <vetch> Luke-Jr: just make the leveldb files bigger than 32mb, that's confirmed to work
241 2014-04-15 15:07:41 <Luke-Jr> vetch: ?
242 2014-04-15 15:07:53 <GAit> out of curiousity, anyone here using antvirus on their personal box?
243 2014-04-15 15:08:08 <Luke-Jr> GAit: I doubt it, we all use Linux
244 2014-04-15 15:08:09 <vetch> Luke-Jr: if the leveldb files are larger than 32mb they are ignored by most virus protection suites.
245 2014-04-15 15:08:24 <vetch> Luke-Jr: it sounds stupid, but true.
246 2014-04-15 15:08:28 <Luke-Jr> vetch: wtf
247 2014-04-15 15:08:56 <vetch> literally just padding out the files will do
248 2014-04-15 15:08:57 <Luke-Jr> GAit: even Bitcoin Core for Windows, is entirely compiled on Linux
249 2014-04-15 15:09:09 <Luke-Jr> vetch: sounds ugly.
250 2014-04-15 15:09:24 <GAit> didn't realize it was cross compiled, that's cool
251 2014-04-15 15:09:24 <maaku> Michail1: you should be able to disable scanning of just the bitcoin directory
252 2014-04-15 15:09:56 <Luke-Jr> GAit: oh, it gets even cooler.. :P
253 2014-04-15 15:09:58 <GAit> Luke-Jr: while there are just a few AV on linux there are and people can still write viruses for it. I just don't find them any useful.
254 2014-04-15 15:10:06 <vetch> Luke-Jr: someone was messing about with it on bitcointalk. you can break the scanning very easy.
255 2014-04-15 15:10:36 <Luke-Jr> GAit: we actually have it setup so that multiple independent parties do the cross-compile and get a bit-for-bit identical build. releases require 3+ PGP signatures from independent builders
256 2014-04-15 15:10:50 <hearn> vetch: yeah but that’s fragile
257 2014-04-15 15:10:58 <hearn> better to just XOR the scripts
258 2014-04-15 15:11:03 <vetch> heck, even just XORing the files on windows would do.
259 2014-04-15 15:11:10 <GAit> yeah i was reading about it and someone probably hearn was saying bitcoinj is going to have a similar release?
260 2014-04-15 15:11:16 <Luke-Jr> vetch: that was what I suggested :P
261 2014-04-15 15:11:27 <hearn> a similiar issue, you mean?
262 2014-04-15 15:11:39 <vetch> Luke-Jr, hearn: great minds or something.
263 2014-04-15 15:12:22 <hearn> GAit: SPV clients don’t store the block chain locally. so, no.
264 2014-04-15 15:12:39 <Michail1> maaku - Yes, setting to ignore the Silly.218 virus
265 2014-04-15 15:12:44 <Michail1> 3946971FE6D4%7D&partnerid=Symantec&lic_type=64&lic_attr=152594&osvers=6.1&oslocale=iso:USA&oslang=iso:ENG&os=windows
266 2014-04-15 15:12:44 <Michail1> http://www.symantec.com/security_response/detected_writeup.jsp?name=Silly.218&vid=35606&prod=scss&product=Norton%20Security%20Suite&version=21.2.0.38&plang=sym:EN&layouttype=SOS&buildname=SymantecPartner&heartbeatID=BD0A44B1-0E93-4B3F-BC5C-3946971FE6D4&env=prod&ispid=1122&sitename=US&vendorid=Symantec&plid=0&skup=21317287&skum=21317287&skuf=21291129&endpointid=%7BBD0A44B1-0E93-4B3F-BC5C-
267 2014-04-15 15:12:45 <Michail1> oops
268 2014-04-15 15:12:59 <GAit> hearn: I just seem to recall someone saying they wanted to adopt the same release method used for the bitcoin core binaries
269 2014-04-15 15:13:07 <hearn> release method?
270 2014-04-15 15:13:08 <maaku> well i wouldn't ignore the virus entirely, but just configure your antivirus to not scan the bitcoin data directory
271 2014-04-15 15:13:21 <hearn> i’m not sure what you’re talking about
272 2014-04-15 15:13:23 <Michail1> yup.
273 2014-04-15 15:13:24 <maaku> hearn: gitian
274 2014-04-15 15:13:28 <GAit> hearn: [15:10] <Luke-Jr> GAit: we actually have it setup so that multiple independent parties do the cross-compile and get a bit-for-bit identical build. releases require 3+ PGP signatures from independent builders
275 2014-04-15 15:13:47 <hearn> Michail1: no that’s the wrong fix. you need to tell your AV to ignore that directory entirely, not ignore that virus. someone stuffed a lot of AV signatures into the block chain.
276 2014-04-15 15:14:02 <hearn> Michail1: and scanning SST files slows down your computer a lot. just exclude that directory
277 2014-04-15 15:14:28 <Michail1> understood.
278 2014-04-15 15:14:47 <hearn> GAit: we would not be using gitian, no
279 2014-04-15 15:15:32 <GAit> hearn: then it must have been someone else or i must have confused what i heard
280 2014-04-15 15:16:58 <hearn> GAit: yeah not sure what you’re thinking of there. we’ll do deterministic builds at some point - actually 0.11 was done deterministically
281 2014-04-15 15:17:03 <hearn> or rather the build was reproduced afterwards
282 2014-04-15 15:17:13 <hearn> you don’t really need to do anything to get a deterministic java build, except use the same version of the JDK
283 2014-04-15 15:18:07 <GAit> hearn: isn't that the same with bitcoin core if you use the exact same tool chain?
284 2014-04-15 15:18:37 <hearn> yes, in theory. the gitian vm stuff has always seemed like overkill to me.
285 2014-04-15 15:18:53 <hearn> in practice matching a toolchain for C++ is a lot harder
286 2014-04-15 15:19:17 <GAit> yeah it's a pain but if you use tools like saltstack it isn't hard at all
287 2014-04-15 15:31:30 <hno> Hmm.. which is the most recent testnet3 blockhash now?
288 2014-04-15 15:33:56 <daemon> C0 3E 03 00                                                                   - Last block sending node has is block #212672
289 2014-04-15 15:34:02 <daemon> but what if you have received nothing so far, should it be 00 00 00 00
290 2014-04-15 15:35:16 <hno> daemon, that can't be right. That block is from Apr 9.
291 2014-04-15 15:36:02 <vetch> 000000000001bf838a2364dd6598d0b3331f87416024f1c321cc59e153d8e01d
292 2014-04-15 15:36:35 <daemon> hno, im just not sure what to put in, I have not seen any blocks yet
293 2014-04-15 15:36:58 <sipa> daemon: send 0 in that case
294 2014-04-15 15:37:11 <daemon> ok
295 2014-04-15 15:37:48 <daemon> sipa, would you be willing to look at a packet I have generated and tell me if its correct
296 2014-04-15 15:38:43 <daemon> in hex ofc
297 2014-04-15 15:38:55 <hno> vetch, I kind of doubt that's the latest one. Dated Tue Apr 15 02:23:06 GMT 2014.
298 2014-04-15 15:39:43 <maaku> sipa: which of your headersfirst branches is most current?
299 2014-04-15 15:40:30 <sipa> maaku: headersfirst is the working-old-but-likely-buggy implementation of the whole thing
300 2014-04-15 15:40:49 <sipa> maaku: headersfirst2,3,4,5 are parts of the new implementation which isn't finished
301 2014-04-15 15:41:02 <maaku> ok thanks
302 2014-04-15 15:41:35 <hearn> sipa: how much work remains?
303 2014-04-15 15:41:47 <sipa> (in particular, even headersfirst5 doesn't do anything that could be called 'headers first', it's all just refactorings and preparatory work)
304 2014-04-15 15:42:11 <vetch> hno: you're right. I was looking at my local block explorer that seems to be behind. #225121 seems to be my current highest.
305 2014-04-15 15:42:12 <sipa> and i think i'll have a part 6 today :)
306 2014-04-15 15:42:34 <maaku> sipa: i may have time to work on this in a few days time as well
307 2014-04-15 15:43:16 <hno> vetch, ok, thats 0000000014259333fc513182e944cafdc78343013b861086a82c28b5d207c403?
308 2014-04-15 15:43:18 <daemon> sipa, sorry got DC, so yeah woudl you be able to look at a hex dump of a packet I have formed
309 2014-04-15 15:43:18 <sipa> oh right, and i have to address hearn's comments in 5
310 2014-04-15 15:43:24 <daemon> see if it looks right
311 2014-04-15 15:43:24 <sipa> daemon: no time now, sorry
312 2014-04-15 15:43:32 <daemon> ok dokey
313 2014-04-15 15:43:43 <vetch> hno: yes that's my current tip.
314 2014-04-15 15:43:46 <daemon> if anyone else would be able to qualify it: http://pastebin.com/raw.php?i=iF3KjJWu
315 2014-04-15 15:43:52 <daemon> standard version packet
316 2014-04-15 15:44:40 <hno> none of the testnet block chain web sites I know of seems to work right now. Still don't trust my bitcoinds to stay on the main chain after last days headaches.
317 2014-04-15 15:44:57 <hno> but seems the are today :)
318 2014-04-15 15:45:33 <vetch> hno: that's very odd. insight is behind, btclook isn't, webbtc is.
319 2014-04-15 15:46:35 <vetch> blockexplorer is behind too.
320 2014-04-15 15:47:12 <hno> Seems there have been a chain reorg again.
321 2014-04-15 15:47:32 <vetch> wasn't me this time.
322 2014-04-15 15:49:38 <vetch> these block explorers really don't like handling reorganisations. I suppose they don't happen in very large chains on mainnet so they never get tested.
323 2014-04-15 16:09:39 <dcousens> hey all, so just getting my head around multisig again (for the n'th time), and was just curious, how do you represent a multisig output script as an address?
324 2014-04-15 16:10:01 <sipa> dcousens: P2SH
325 2014-04-15 16:10:14 <dcousens> sipa: not P2SH, I mean multisig in the scriptPubKey
326 2014-04-15 16:10:20 <sipa> raw multisig isn't representable as an address (and discouraged)
327 2014-04-15 16:10:58 <justanotheruser> sipa: what do you mean? Isn't p2sh represented by an address with a 3?
328 2014-04-15 16:11:12 <dcousens> sipa: right, as I thought, just wanted to check
329 2014-04-15 16:11:27 <sipa> justanotheruser: P2SH multisig is, raw multisig isn't
330 2014-04-15 16:12:35 <dcousens> sipa: why is it discouraged? out of interest
331 2014-04-15 16:12:35 <justanotheruser> Why is it discouraged?
332 2014-04-15 16:12:57 <sipa> requires more space in the UTXO set, has worse privacy
333 2014-04-15 16:13:30 <sipa> (and a tiny security disadvantage as it means revealing the actual public keys, which have lower security than computing an address preimage)
334 2014-04-15 16:15:14 <dcousens> sipa: right, and I guess because of the need for the public keys, there isn't really a 20 byte hash shortcut anyway?
335 2014-04-15 16:15:23 <justanotheruser> sipa: well you have to reveal public keys anyway as long as its confirmed. I guess the difference is someone has 10 minutes to crack your key rather than the amount of time it takes to spend it
336 2014-04-15 16:15:35 <sipa> justanotheruser: indeed
337 2014-04-15 16:16:06 <justanotheruser> Which leads me to the question of what will happen to satoshis coins when ecdsa is crackable?
338 2014-04-15 16:16:30 <sipa> hope that he moves his coins like everybody else, if that happens
339 2014-04-15 16:16:49 <justanotheruser> I doubt that he owns the majority of the coins.
340 2014-04-15 16:16:56 <sipa> relevance?
341 2014-04-15 16:17:31 <justanotheruser> A million new coins become spendable
342 2014-04-15 16:18:10 <sipa> and many more
343 2014-04-15 16:18:41 <justanotheruser> Is it possible that a hardfork will say "move all your coins to this better crypto, or they become unspendable by block X"?
344 2014-04-15 16:18:59 <justanotheruser> Or would devs not agree to that
345 2014-04-15 16:19:04 <sipa> if that is the only way to avoid Inevitable Doom (tm), yes
346 2014-04-15 16:19:23 <sipa> in every other case, i would say it's against bitcoin's social contract of never touching anyone's coins
347 2014-04-15 16:19:48 <dcousens> anyway, thanks sipa, just wanted to confirm that :)
348 2014-04-15 16:20:15 <justanotheruser> I suppose it is... I hope it happens myself
349 2014-04-15 16:20:36 <dcousens> justanotheruser: hope?
350 2014-04-15 16:21:06 <sipa> i think bitcoin has very uncertain survival if that happens suddenly
351 2014-04-15 16:21:44 <sipa> but i don't expect that to happen; there will be improvements to ecdsa crackability that are only theoretical long before there is a computationally feasible attack
352 2014-04-15 16:22:10 <dcousens> sipa: out of interest, how would you query a raw multisig pubkey tuple? I guess you can't really?
353 2014-04-15 16:22:11 <justanotheruser> I think when it happens either bitcoin will be the dominant global currency and the price will only divide by the % of non-stolen coins, or it won't be the dominant global currency and the price will crash
354 2014-04-15 16:22:26 <sipa> dcousens: 'query' ?
355 2014-04-15 16:24:06 <dcousens> For example, say I had an output that was a multisig: m pubks n OP_CHECKMULTISIG,    and someone else wanted to just quickly send some more coin on to that same output, due to the information requirement (they need the pubkeys), as I said before, there is no simple way of giving them that as an output
356 2014-04-15 16:24:32 <sipa> well you'll have to give them the actual script
357 2014-04-15 16:24:37 <dcousens> aka, as I said before, a 20byte hash isn't really feasible
358 2014-04-15 16:24:39 <sipa> and he'll need a client that supports that
359 2014-04-15 16:24:48 <sipa> well, sure it is... that's P2SH :p
360 2014-04-15 16:24:54 <dcousens> haha exactly
361 2014-04-15 16:25:06 <sipa> only it's a 20-byte hash of the entire script, rather than of just the pubkeys
362 2014-04-15 16:27:59 <dcousens> sipa: if you know, how does the reference client show the user they have a partial stake in a pubkey output? (by stake, I mean someone used a pubkey they own)
363 2014-04-15 16:28:18 <sipa> 'partial'?
364 2014-04-15 16:28:42 <sipa> the reference client will only consider a coin yours if you have _all_ private keys involved, as it can't deal with spendability from different locations
365 2014-04-15 16:29:18 <sipa> if it's to a normal single-pubkey script, it's considered to be identical to a pubkeyhash output
366 2014-04-15 16:29:49 <dcousens> say you had tx with output 2 pkA pkB 2 OPCMS,   and you own the private key for pkB, does the reference client notify you of this tx at all?
367 2014-04-15 16:31:30 <dcousens> given what you just said, it sounds like it wouldn't
368 2014-04-15 16:31:34 <sipa> no
369 2014-04-15 16:31:45 <sipa> it'll just ignore it
370 2014-04-15 16:33:50 <dcousens> interesting, cheers :)
371 2014-04-15 16:35:47 <dcousens> sipa: though, all this hardly matters since it appears as though raw multisig is pretty much just used for data at the moment haha
372 2014-04-15 16:59:22 <GAit> just to avoid making mistakes _again_, is it best practise to ask some on the chan before msg'ing them privately? in which case, sipa when you have a second can I disturb you privately?
373 2014-04-15 17:01:40 <daemon> GAit, yes always best practise on freenode
374 2014-04-15 17:01:46 <daemon> people get annoyed VERY quickly if you don't ;)
375 2014-04-15 17:02:24 <GAit> daemon: thanks, at first I just thought it was the individual preference but fair enough
376 2014-04-15 17:02:40 <megaworm> I am starting a new pool similar to blackcoinpool.com.  I am looking for experienced pool operators who would like to partner with me.  I am a designer/frontend developer with experience in branding and marketing.  Please contact me via PM or email wearesatoshifoundation@gmail.com for more details.
377 2014-04-15 17:20:02 <megaworm> any pool operators in here?
378 2014-04-15 17:55:06 <megaworm> any pool operators in here?
379 2014-04-15 18:00:24 <MaxSan> megaworm Luke-Jr
380 2014-04-15 18:00:49 <Apocalyptic> wizkid057 is now in charge of Eligius I heard
381 2014-04-15 18:01:14 <MaxSan> ah
382 2014-04-15 18:04:21 <megaworm> thx MaxSan
383 2014-04-15 18:08:40 <justanot1eruser> megaworm: what pool?
384 2014-04-15 18:09:32 <megaworm> justanot1eruser: any pool
385 2014-04-15 18:09:44 <megaworm> preferably a good one with an experienced operator / dev
386 2014-04-15 18:10:30 <justanot1eruser> oh, I misunderstood, I thought he was saying you were a pool operator. Luke-Jr Eligius]
387 2014-04-15 18:10:45 <justanot1eruser> s/Eligius/runs Eligius
388 2014-04-15 18:13:25 <jgarzik> justanot1eruser, wizkid057 runs Eligius
389 2014-04-15 18:15:07 <justanot1eruser> jgarzik: what? What does Luke-Jr do then?
390 2014-04-15 18:15:29 <jgarzik> justanot1eruser, hacks in eloipool and bfgminer
391 2014-04-15 18:15:58 <justanot1eruser> jgarzik: what do you mean by "hacks in"?
392 2014-04-15 18:18:13 <jgarzik> justanot1eruser, maintains software
393 2014-04-15 18:19:11 <justanot1eruser> jgarzik: Did he at least start Eligius?
394 2014-04-15 18:19:21 <justanot1eruser> It is named after a saint after all
395 2014-04-15 18:20:15 <phantomcircuit> justanot1eruser, yeah he did
396 2014-04-15 18:20:21 <hno> justanot1eruser, he is still involved in Eligius. But not so much day to day operations.
397 2014-04-15 18:40:45 <hno> Do getblocks always give you only main-chain blocks? How do thin clients detect if they are on the main chain if getheaders don't?
398 2014-04-15 18:42:36 <hno> or do thin clients combine both getblocks and getheaders?
399 2014-04-15 19:05:34 <sipa> hno: getblocks and getheaders behave identically, and i believe they only reveal currently active blocks
400 2014-04-15 19:57:29 <WOODMAN> hello
401 2014-04-15 19:57:35 <WOODMAN> may i ask a question
402 2014-04-15 19:57:48 <WOODMAN> serious serious question
403 2014-04-15 19:58:05 <Ry4an> DATAJA
404 2014-04-15 19:58:16 <WOODMAN> is that a yes
405 2014-04-15 19:58:56 <WOODMAN> got a major headache going on  over here and could use some help
406 2014-04-15 19:59:34 <Ry4an> It means there's no value in asking if you can ask a question.  Just ask and someone will let you know if you're off topic.
407 2014-04-15 19:59:45 <WOODMAN> kk
408 2014-04-15 20:00:41 <WOODMAN> i was meticulous when i set up wallet QT, i set it up in advance of buying or trading in person.......i set up the receiving addresses and then i encyrpted the wallet as i never found any real user friendly manuals other than what was on the main website where wallet download (QT) was
409 2014-04-15 20:00:56 <WOODMAN> i traded a couple of times as investment, i go to send and wont send
410 2014-04-15 20:01:15 <WOODMAN> so if i set up receive adddress before encryption can this problem be resovled
411 2014-04-15 20:01:18 <WOODMAN> ?
412 2014-04-15 20:01:38 <WOODMAN> again i never read anywhere that i had to set up recieve address AFTER encrption cause it changes the keys
413 2014-04-15 20:01:47 <WOODMAN> now i wonder can this issue somehow be resolved
414 2014-04-15 20:02:25 <vetch> receive addresses stay the same through wallet encryption.
415 2014-04-15 20:02:41 <WOODMAN> but the keys change
416 2014-04-15 20:02:48 <WOODMAN> thus the problem i believe
417 2014-04-15 20:02:51 <vetch> the keypool is erased, but that doesn't effect addresses already in your wallet.
418 2014-04-15 20:03:03 <WOODMAN> ok
419 2014-04-15 20:03:17 <WOODMAN> then why is the not sending?
420 2014-04-15 20:03:38 <vetch> it effects backups of your wallet, in that your old backups are likely invalid, but doesn't change anything beyond that.
421 2014-04-15 20:03:40 <WOODMAN> and thanks for the answer
422 2014-04-15 20:04:19 <vetch> I don't really know, I don't use the Core client.
423 2014-04-15 20:04:28 <WOODMAN> yah this thing is a joke
424 2014-04-15 20:04:50 <WOODMAN> the technology may be great, the manuals that go along with it suck
425 2014-04-15 20:04:56 <WOODMAN> its all over the internet
426 2014-04-15 20:05:03 <WOODMAN> not on a homepage warning people
427 2014-04-15 20:05:28 <WOODMAN> i have one hell of a mystery going on
428 2014-04-15 20:05:38 <WOODMAN> and its not treating me well
429 2014-04-15 20:06:31 <WOODMAN> its not recognizing the passphrase
430 2014-04-15 20:06:38 <WOODMAN> i wrote it down
431 2014-04-15 20:06:44 <WOODMAN> tried to crack it or crunch it
432 2014-04-15 20:07:01 <WOODMAN> was able to tell that it wasnt capitlization or being one character off
433 2014-04-15 20:07:10 <WOODMAN> but still didnt resolve issue
434 2014-04-15 20:08:40 <WOODMAN> i would like to offer a big suggestion if i may
435 2014-04-15 20:09:06 <WOODMAN> that the homepage tell people with bold (since there are a lot of new people) to 1. test wallet before loading with any real amount
436 2014-04-15 20:09:34 <WOODMAN> 2. get the import key first before loading it in case smeting goes wrong, caues if i had it would be very helpful in this situation
437 2014-04-15 20:09:55 <WOODMAN> 3. dont add RECEIVE addresses until after encryption
438 2014-04-15 20:10:19 <WOODMAN> what do you think?
439 2014-04-15 20:10:39 <WOODMAN> i wouldnt wish this upon anyone else even if i had to take it on the chin
440 2014-04-15 20:10:47 <WOODMAN> this one hurt bad
441 2014-04-15 20:11:31 <jcorgan> WOODMAN: sorry to hear about what happened to you, but this channel is primarily for the bitcoin developers to coordinate work on the reference client; you'll probably get more help from #bitcoin
442 2014-04-15 20:15:52 <WOODMAN> alright
443 2014-04-15 20:16:06 <WOODMAN> thought the devlopers should konw
444 2014-04-15 20:16:14 <WOODMAN> fyi