1 2013-03-18 00:25:24 <montesquieu> This block is going to be big
  2 2013-03-18 00:25:43 <montesquieu> maybe big enough for a fork like last week
  3 2013-03-18 00:28:35 <kaptah> 54kB
  4 2013-03-18 00:28:44 <Line_> =[
  5 2013-03-18 00:30:12 <pizzacat> it had to be way over 500Kb right?
  6 2013-03-18 00:31:12 <pizzacat> then again.. most of the big mining pools are on 0.7.2, or a modified 0.8.0 to be compatible
  7 2013-03-18 00:31:24 <pizzacat> or did i miss something? xD
  8 2013-03-18 00:31:30 <montesquieu> sorry guys, blockchain.info was about 8 blocks behind on their data
  9 2013-03-18 00:31:48 <montesquieu> i was expecting about 1300 txs and over 1000 KB size
 10 2013-03-18 00:32:07 <sipa> "over 1000 KB size" is simply illegal, by any bitcoin version ever
 11 2013-03-18 00:32:15 <montesquieu> sipa: oh?
 12 2013-03-18 00:32:24 <montesquieu> the fork last week was 975 KB
 13 2013-03-18 00:32:32 <sipa> yes
 14 2013-03-18 00:32:58 <gritcoin> Could (hypothetically) the target be made dependent on the # of txs in the block?
 15 2013-03-18 00:33:21 <gritcoin> Or is that a massive attack target...
 16 2013-03-18 00:33:38 <doublec> montesquieu: since the fork most pools have gone back to conservative block sizes I think
 17 2013-03-18 00:33:42 <pizzacat> montesquieu, i'm working on a website on this..
 18 2013-03-18 00:33:59 <montesquieu> pizzacat: good
 19 2013-03-18 00:34:37 <montesquieu> doublec: when the 'good' chain took back over (higher height) many people may have gone back to 0.8.0
 20 2013-03-18 00:34:55 <pizzacat> montesquieu, it's not completely done (0.8.0 is updating chain and 0.8.1 is being installed), i can pm you link
 21 2013-03-18 00:35:08 <BCB> more asics on 0.8.0
 22 2013-03-18 00:35:13 <montesquieu> pizzacat: sure
 23 2013-03-18 00:35:23 <montesquieu> BCB: thats probably true
 24 2013-03-18 00:35:46 <swhitt> BCB: that could make things interesting, eh?
 25 2013-03-18 00:35:55 <montesquieu> gritcoin: the size over block is correlated to number of txs
 26 2013-03-18 00:36:31 <BCB> swhitt I think it is true
 27 2013-03-18 00:36:52 <gritcoin> Right; I'm wondering if a block's validity vis a vis the target could be defined so that if a lot of txns were included the target could be higher, meaning the block interval would depend on the txn rate
 28 2013-03-18 00:36:52 <swhitt> montesquieu: the clients all have a hard limit of 1k right now
 29 2013-03-18 00:37:04 <sipa> gritcoin: why would you want that?
 30 2013-03-18 00:37:19 <montesquieu> ok then, if we are limiting block size, then there is a theoretical tx limit as well...
 31 2013-03-18 00:37:31 <swhitt> montesquieu: there was a soft limit of 500k set on all clients but about 2 weeks ago pool operators were told to increase it due to increased #s of txs
 32 2013-03-18 00:37:36 <montesquieu> gritcoin: that's not how the 'difficulty' works
 33 2013-03-18 00:37:45 <swhitt> montesquieu: 0.8 could handle it but 0.7 could not.
 34 2013-03-18 00:37:49 <montesquieu> swhitt: this is my point
 35 2013-03-18 00:37:50 <gritcoin> Or, make it block size. sipa: To limit block size by making target converge to something very high as blocksize approaches limit
 36 2013-03-18 00:38:08 <swhitt> BCB: i think 0.8's default blocksize is still 512k
 37 2013-03-18 00:38:24 <gritcoin> I know that's not how the difficulty works, montesquieu; I'm wondering about the feasibility of such an approach.
 38 2013-03-18 00:38:28 <swhitt> gritcoin: you should read the old debates on bitcointalk
 39 2013-03-18 00:38:30 <montesquieu> swhitt: if bitcoin usage triple over night (lots of adoption) a HUGE number of tx would not be confirmed for a very long time
 40 2013-03-18 00:38:38 <swhitt> PoW/PoS is fun
 41 2013-03-18 00:38:59 <swhitt> montesquieu: that's what tx priority and tx fees are for.
 42 2013-03-18 00:39:09 <swhitt> to mitigate that issue until it needs addressing
 43 2013-03-18 00:39:15 <gmaxwell> swhitt: 250k.
 44 2013-03-18 00:39:29 <swhitt> gmaxwell: sorry. it seems like whenever I talk about the protocol you correct me :)
 45 2013-03-18 00:39:44 <sipa> swhitt: technically, you weren't talking about the protocol at all :p
 46 2013-03-18 00:39:51 <sipa> (the protocol allows up to 1000 kB)
 47 2013-03-18 00:39:57 <swhitt> being technically right is the best kind of right
 48 2013-03-18 00:40:06 <gmaxwell> Which was reduced from the prior target of 500k in 0.7.x (though this target required very high fees to hit), so hey, not totally confused.
 49 2013-03-18 00:40:35 <swhitt> between the wiki (which is not always up to date), BCT, talk on here and reading the source I can get confused
 50 2013-03-18 00:40:44 <montesquieu> swhitt: thats surprising to me, if usage triples soon, we could see required tx fees triple as well, in a snap
 51 2013-03-18 00:41:03 <swhitt> montesquieu: stilll that'd only be 0.0015 btc
 52 2013-03-18 00:41:04 <montesquieu> until btc tx fees compare to fiat
 53 2013-03-18 00:41:24 <swhitt> unless you have aged coin
 54 2013-03-18 00:41:32 <swhitt> then the required fee disappears
 55 2013-03-18 00:41:46 <swhitt> although I've had difficulty finding the exact calculation the current clients use for priority
 56 2013-03-18 00:42:01 <swhitt> and figuring out which mining pools respect those rules vs have their own is difficult too
 57 2013-03-18 00:43:07 <doublec> swhitt: there's a thread on bitcointalk that the pools are using to outline their fee/blocksize/etc structure
 58 2013-03-18 00:43:23 <keystroke> how is 0.8.1?
 59 2013-03-18 00:43:25 <montesquieu> swhitt: and when *everyone* is sending 0.0015 btc fees (because thats what it takes to get through) we could see a serious jump
 60 2013-03-18 00:43:37 <swhitt> doublec: any chance you can link me? I can dig through the search results but it's somewhat painful.
 61 2013-03-18 00:43:40 <doublec> swhitt: https://bitcointalk.org/index.php?topic=151387.0
 62 2013-03-18 00:43:47 <swhitt> doublec: beat me to it, thanks
 63 2013-03-18 00:44:10 <doublec> swhitt: it's currently stalled due to the blockfork situation but once miners have updated they'll repost what they're setting I think
 64 2013-03-18 00:44:28 <swhitt> hopefully pools will update to reasonable settings that prevent forkage in the meantime?
 65 2013-03-18 00:44:38 <Graet> they did
 66 2013-03-18 00:44:43 <gavinandresen> keystroke: 0.8.1 is ready: https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.1/
 67 2013-03-18 00:44:45 <Graet> or it would have happened again :)
 68 2013-03-18 00:44:55 <keystroke> awesome, thanks gavin :)
 69 2013-03-18 00:44:57 <swhitt> Graet: weren't they just reverting to 0.7 defaults?
 70 2013-03-18 00:45:05 <gavinandresen> keystroke: 0.8.1 will be officially announced tomorrow
 71 2013-03-18 00:45:14 <keystroke> is there a changelog?
 72 2013-03-18 00:45:22 <doublec> swhitt: that strikes me as being a reasonable setting
 73 2013-03-18 00:45:26 <Graet> pools reverted to sane settings
 74 2013-03-18 00:45:43 <swhitt> that depends on one's definition of 'sane'
 75 2013-03-18 00:45:44 <Graet> awaiting 0.8.1 so we can get past this :)
 76 2013-03-18 00:45:48 <keystroke> gpg: Good signature from "Gavin Andresen (CODE SIGNING KEY) <gavinandresen@gmail.com>"
 77 2013-03-18 00:45:51 <gavinandresen> keystroke: see https://github.com/bitcoin/bitcoin/commits/master for the 3 commits that are the difference from 0.8.0
 78 2013-03-18 00:46:26 <gavinandresen> keystroke: bah, wrong url
 79 2013-03-18 00:46:33 <Graet> sane enough not to have had another fork swhitt ?
 80 2013-03-18 00:46:45 <gavinandresen> keystroke: https://github.com/bitcoin/bitcoin/commits/0.8.1
 81 2013-03-18 00:47:13 <gavinandresen> (that's why I'm not going to Officially Announce it tonight, too late, I'll make dumb mistakes....)
 82 2013-03-18 00:47:15 <swhitt> any reason the packages aren't posted on github instead of sourceforge?
 83 2013-03-18 00:47:26 <keystroke> thanks, just installed it :)
 84 2013-03-18 00:47:30 <gavinandresen> swhitt: github doesn't allow big binaries
 85 2013-03-18 00:47:56 <jgarzik> gavinandresen: anything in v0.8.1 branch that also belongs in HEAD?
 86 2013-03-18 00:48:06 <sipa> Graet: so, technically 0.8.1 does a soft fork on thursday, as it makes the rules slightly stronger compared to 0.7
 87 2013-03-18 00:48:09 <jgarzik> gavinandresen: HEAD should not fall behind
 88 2013-03-18 00:48:20 <gavinandresen> jgarzik: yes, but we should fix pull-tester first or we'll get lots of failed pull spam
 89 2013-03-18 00:48:23 <swhitt> gavinandresen: the README says 2012 still
 90 2013-03-18 00:48:36 <jgarzik> ugh
 91 2013-03-18 00:48:37 <phantomcircuit> it's not 2012 still?
 92 2013-03-18 00:48:38 <phantomcircuit> 
ACTION checks calendar

 93 2013-03-18 00:48:45 <keystroke> so people have 2 months to upgrade?
 94 2013-03-18 00:48:59 <sipa> Graet: initially the plan was to enforce the new temporary ("like 0.7") rule to take effect immediately, but that effectively holds another fork risk if no majority of hash power enforces it
 95 2013-03-18 00:49:00 <swhitt> i thought github allowed larger downloads to be posted on their downloads tab
 96 2013-03-18 00:49:02 <gavinandresen> upgrade or add a DB_CONFIG file to their datadir, yes
 97 2013-03-18 00:49:12 <jgarzik> gavinandresen: I think the other way around is more likely to result in rapid pull-tester fixes ;p
 98 2013-03-18 00:49:20 <gavinandresen> keystroke: oh, and it is 4 commits, not 3 ....
 99 2013-03-18 00:49:32 <jgarzik> gavinandresen: (a) upgrade, (b) patch or (c) DB_CONFIG, you mean?
100 2013-03-18 00:49:41 <Graet> yep cool sipa , looking forward to the upgrade :)
101 2013-03-18 00:49:45 <gavinandresen> jgarzik: yes, upgrade patch or DB_CONFIG
102 2013-03-18 00:50:50 <jgarzik> gavinandresen: I'm mining on HEAD, so having orphan-inducing code on a branch > pull tester
103 2013-03-18 00:50:51 <jgarzik> IMO
104 2013-03-18 00:51:15 <phantomcircuit> so people still using bdb should add the configuration file to increase the lock count?
105 2013-03-18 00:51:19 <gavinandresen> jgarzik: agreed, we need to pull into HEAD before thursday.
106 2013-03-18 00:51:21 <swhitt> jgarzik: how many blocks/day are you pulling now?
107 2013-03-18 00:51:22 <sipa> phantomcircuit: indeed
108 2013-03-18 00:51:24 <jgarzik> plus, there are several good reasons why you want to do "upstream first" (HEAD first) for any bug fixes
109 2013-03-18 00:51:34 <jgarzik> swhitt: Four blocks in past 3 days
110 2013-03-18 00:51:35 <jgarzik> <grin>
111 2013-03-18 00:51:39 <Rebroad> was the block that caused the fork created intentionally to cause the fork?
112 2013-03-18 00:51:40 <jgarzik> far above average, I grant
113 2013-03-18 00:51:43 <swhitt> jgarzik: you lucky bastard
114 2013-03-18 00:51:47 <sipa> Rebroad: no
115 2013-03-18 00:51:51 <CodeShark> Rebroad: unlikely
116 2013-03-18 00:52:14 <sipa> given that the pool that created it switched back to old rules afterwards
117 2013-03-18 00:52:24 <Rebroad> ah, thanks, just asking as someone on bitcointalk said it was.
118 2013-03-18 00:52:29 <gavinandresen> jgarzik: I could cherry-pick into head right now...
119 2013-03-18 00:52:38 <sipa> gavinandresen: ACK
120 2013-03-18 00:52:42 <jgarzik> gavinandresen: ACK
121 2013-03-18 00:53:06 <Rebroad> are there any plans to make the client warn (or go into safe mode) if it's seen that another chain is catching up with the one currently in use?
122 2013-03-18 00:53:38 <CodeShark> or growing at all, Rebroad :)
123 2013-03-18 00:53:43 <CodeShark> doesn't have to be catching up
124 2013-03-18 00:53:46 <Rebroad> CodeShark, indeed..
125 2013-03-18 00:54:10 <gavinandresen> jgarzik sipa : ok, quick make test and then I'll push....
126 2013-03-18 00:54:15 <Rebroad> I'd love to see a nice GUI to the block situation, perhaps along the lines of the graphics in "world of goo"!
127 2013-03-18 00:54:25 <sipa> Rebroad: feel free to write that :)
128 2013-03-18 00:54:27 <pizzacat> btc.pizzacat.net
129 2013-03-18 00:54:33 <pizzacat> http://btc.pizzacat.net
130 2013-03-18 00:54:39 <pizzacat> xD
131 2013-03-18 00:54:52 <pizzacat> almost on track
132 2013-03-18 00:55:05 <RoboTeddy> Rebroad: here's another GUI that shows forks: http://blockchain.info/orphaned-blocks
133 2013-03-18 00:55:11 <swhitt> what is this for pizzacat?
134 2013-03-18 00:55:19 <keystroke> so 0.8.1 is a hard fork?
135 2013-03-18 00:55:41 <sipa> keystroke: 0.8.1 will cause a hard fork after may 15th
136 2013-03-18 00:55:58 <swhitt> isn't deepbit still running 0.3 or something
137 2013-03-18 00:56:01 <keystroke> awesome :)
138 2013-03-18 00:56:01 <sipa> yes
139 2013-03-18 00:56:09 <pizzacat> swhitt, pure fun and learning from my point of view
140 2013-03-18 00:56:20 <Rebroad> is it a backwards compatible hardfork?
141 2013-03-18 00:56:45 <keystroke> a hardfork by definition can't be backwards compatible
142 2013-03-18 00:56:53 <doublec> deepbit are still mining version 1 blocks. where 13% away from a supermajority there so they have to update their blocks before then don't they?
143 2013-03-18 00:56:59 <doublec> s/where/we're/
144 2013-03-18 00:57:10 <Rebroad> why are deepbit still on version 1?
145 2013-03-18 00:57:17 <doublec> old bitcoind
146 2013-03-18 00:57:26 <sipa> 0.3.19 or so
147 2013-03-18 00:57:31 <Rebroad> why don't they update it?
148 2013-03-18 00:57:31 <sipa> ancient
149 2013-03-18 00:57:38 <gavinandresen> heavily patched
150 2013-03-18 00:57:39 <doublec> Rebroad: lots of custom patches
151 2013-03-18 00:57:48 <Rebroad> erk...
152 2013-03-18 00:57:55 <Rebroad> poor deepbit..
153 2013-03-18 00:58:05 <gavinandresen> happily, the 0.8.1 patch should apply cleanly.
154 2013-03-18 00:58:07 <doublec> I only have minor patches and upgrading is sometimes painful so I can understand their reluctance
155 2013-03-18 00:58:32 <doublec> having left it so long it'll be extremely painful for them
156 2013-03-18 00:58:33 <gwillen> gavinandresen: oh dear; is the code with the may 15 drop-dead date already released? It seems it would be good to actually test the clean application of the patch.
157 2013-03-18 00:59:08 <Rebroad> could the code that deals with block validation be moved in such a way that the changes that cause hard forks are easier to debase into the code for miners who have made customisations?
158 2013-03-18 00:59:17 <Rebroad> *rebase
159 2013-03-18 00:59:36 <sipa> due to the current organisation of the code, that's very hard
160 2013-03-18 00:59:52 <keystroke> how does the  May 8th alert never expire?
161 2013-03-18 01:00:01 <sipa> block and transaction verification is done in several mostly-independent stages (and it should, for DoS protection)
162 2013-03-18 01:00:04 <keystroke> will this always be xmitted by nodes around the network?
163 2013-03-18 01:00:12 <sipa> and they all verify parts of the rules
164 2013-03-18 01:00:16 <Rebroad> I think it's worth reorganisting the code to make it easier for miners to make these customisations and also do the hardforks needed so they're less reluctant to upgrade their daemons
165 2013-03-18 01:01:36 <Rebroad> I'd like to work on an alternative bitcoin-qt, but I'm aware that regarding the upgrade alerts I'd need to change the mechanism for this. luke-jr suggested that polling a website instead of using "alert" would be better, but if that is the case, why isn't the original bitcoin-qt doing this then?
166 2013-03-18 01:02:04 <sipa> Rebroad: it's a core principle not to rely on centralized services
167 2013-03-18 01:02:19 <doublec> if the website gets dos'd, no alerts
168 2013-03-18 01:02:24 <Rebroad> sipa, I know, which is why I think it's worth doing..
169 2013-03-18 01:02:30 <sipa> worth doing what?
170 2013-03-18 01:03:19 <Rebroad> sipa, plus I'm also frustrated at all the features I've been wanting to see added that aren't being... I improved block downloading months ago, but the code has never been included...  I'd like to at least give people an option to use a version that downloads the blockchain quicker.
171 2013-03-18 01:03:46 <Rebroad> sipa, creating another bitcoin-qt variant.
172 2013-03-18 01:03:52 <sipa> Rebroad: then fix it, instead of hacking some rules that just help in your case
173 2013-03-18 01:04:10 <sipa> there's no doubt the download mechanism can be better
174 2013-03-18 01:04:12 <Rebroad> sipa, fix what?
175 2013-03-18 01:04:23 <jgarzik> Rebroad: peer selection
176 2013-03-18 01:04:25 <jgarzik> and rotation
177 2013-03-18 01:04:27 <sipa> we've had this discussion :)
178 2013-03-18 01:05:09 <gavinandresen> gwillen: I'll have patches against 0.3.24 ready tomorrow.  The main 0.8.1 commit does apply cleanly to 0.3.24, at least (didn't try 0.3.19, I think deepbit is the only one running code THAT old)
179 2013-03-18 01:05:17 <gwillen> gavinandresen: *nods*
180 2013-03-18 01:05:24 <Rebroad> sipa.. ah.. were you referring to using a webpage for updates as the "centralized service"? If so, very ironic!
181 2013-03-18 01:05:33 <sipa> Rebroad: how so?
182 2013-03-18 01:05:45 <sipa> Rebroad: right, alerts on itself are centralized
183 2013-03-18 01:05:55 <sipa> Rebroad: there i must agree, if that's what you mean
184 2013-03-18 01:06:06 <Rebroad> yup...
185 2013-03-18 01:06:11 <jgarzik> 
ACTION wonders aloud, if case anybody knows:  One way to "burn money" is to intentionally send it as a transaction fee, thereby donating to the miner.  What is the most efficient "burn money" transaction, sending money to $AnyMiner, considering (a) must have one or more outputs, and (b) zero-value output is non-standard.

186 2013-03-18 01:06:14 <sipa> but let's not go depend on more than centralization than necessary
187 2013-03-18 01:06:18 <keystroke> how can an alert never expire? do they retranmit forever?
188 2013-03-18 01:06:41 <jgarzik> So...  a send-change-to-self TX + fee is the best I can come up with
189 2013-03-18 01:06:49 <Rebroad> and given the alert is client specific, it should only be used with compatible clients. mine would do this, any other behaviour is spammy
190 2013-03-18 01:09:16 <Rebroad> As part of improved block download, I want to add info to debug.log so that each block requested and received is shown an id to link it to the node in use. I'm aware that it's undesired to reveal IP addresses associated with blocks, so it seems the only way I can do this is my changing the debug.log output to now show any IP addresses ever, otherwise the node identiier could be used to associate it with the IP address. is t
191 2013-03-18 01:09:16 <Rebroad> here any reason IP addresses need to be shown in the debug.log file other than for perhaps when a node misbehaves?
192 2013-03-18 01:09:39 <Rebroad> *not
193 2013-03-18 01:09:46 <gavinandresen> Rebroad: it'd be find to show IP addresses if (fDebug) ...
194 2013-03-18 01:10:07 <gavinandresen> ??? then you just run -debug   to get the extra info
195 2013-03-18 01:10:43 <Rebroad> gavinandresen,  when I submitted a pull request previously to show IP addresses of blocks only when a command line flag was stipulated, I believe it was rejected...
196 2013-03-18 01:11:20 <gavinandresen> -debug is already a command line flag.
197 2013-03-18 01:13:26 <Rebroad> gavinandresen, I'd not want most of the information that's displayed in debug.log when -debug is enabled, but I would always like the information about which node is providing blocks  - whether it reveals the IP addresses or not.
198 2013-03-18 01:14:29 <gavinandresen> okey dokey
199 2013-03-18 01:14:54 <Graet> when can we expect 0.8.1 in the ppa? please
200 2013-03-18 01:15:06 <sipa> 
ACTION pokes BlueMatt 

201 2013-03-18 01:15:14 <Rebroad> I realise I could just have -debug on all the time and create another app that filters out the stuff I don't want (making bitcoin output to stdout)... but I'd rather make it a configurable option of bitcoin itself :)
202 2013-03-18 01:16:14 <gavinandresen> I'm not a big fan of configurable options up the wazoo myself, so I'd vote for the "filter debug.log through another app" approach.
203 2013-03-18 01:16:37 <gavinandresen> I'm not a big fan of debug.log either, though.  It needs to go away before we get to a 1.0 release.
204 2013-03-18 01:18:29 <gavinandresen> we should just copy some other application that has solved the debugging/tracing problem well, and do whatever they do.
205 2013-03-18 01:29:45 <rebroad_> gavinandresen, I got your "we should just copy some other application".... hmmm. yeah, I like debug.log, or rather, the info that's contained within it...  it would be good to retain some way to access that information in any future version.
206 2013-03-18 01:32:20 <rebroad_> my bitcoin-qt (build from the latest's master) keeps core dumping... I've forgotten how to make it output a core file, and it's been a while since I used gdb on a core file..!
207 2013-03-18 01:37:13 <swhitt> my 0.8 dies whenever I am required to keypoolrefill i think
208 2013-03-18 01:45:32 <gmaxwell> swhitt: required to?
209 2013-03-18 01:45:46 <swhitt> I'm not sure, trying to reproduce
210 2013-03-18 01:46:15 <swhitt> gmaxwell: does the keypool generate a new address every time you use one in the keypool or only when it is empty?
211 2013-03-18 01:46:24 <sipa> swhitt: everytime
212 2013-03-18 01:46:31 <sipa> swhitt: unless it can't (=it is encrypted)
213 2013-03-18 01:46:46 <swhitt> so there are always 100 addresses (without changing bitcoin.conf/command line addresses)
214 2013-03-18 01:46:48 <swhitt> hm
215 2013-03-18 01:48:10 <swhitt> i need to pay attention to the core dump the next time
216 2013-03-18 01:50:09 <gmaxwell> swhitt: if it only refilled when empty it the keypool would be nearly worthless.
217 2013-03-18 01:50:23 <swhitt> yeah.
218 2013-03-18 01:50:34 <swhitt> i backed up my wallet.dat a month ago
219 2013-03-18 01:50:53 <swhitt> was looking at it with pywallet
220 2013-03-18 01:51:00 <swhitt> are there any good docs about this stuff anywhere?
221 2013-03-18 01:51:13 <gmaxwell> rebroad_: its usually better to run under gdb directly then to try to fuddle things out from a corefile.
222 2013-03-18 01:51:25 <swhitt> If I google it I get https://en.bitcoin.it/wiki/Key_pool
223 2013-03-18 01:51:28 <gmaxwell> swhitt: About what stuff?
224 2013-03-18 01:51:32 <swhitt> but that makes no sense to newbs
225 2013-03-18 01:51:56 <swhitt> Backing up wallet.dat and what it means, what the keypool is, why you need to make sure you have a relatively recent wallet.dat
226 2013-03-18 01:52:36 <swhitt> I can dig through bitcointalk to figure out what's going on but bitcointalk is a bit like tvtropes
227 2013-03-18 01:54:20 <gmaxwell> tvtropes has less misinformation
228 2013-03-18 01:54:33 <swhitt> ^ +1 from me
229 2013-03-18 01:54:49 <swhitt> my wife was interested in bitcoin and she found the forum
230 2013-03-18 01:54:52 <swhitt> and the wiki
231 2013-03-18 01:54:55 <swhitt> and she just got confused
232 2013-03-18 01:55:26 <swhitt> she asked me about keeping her coin safe and I said to back up wallet.dat
233 2013-03-18 01:55:33 <swhitt> but backing up wallet.dat isn't the only thing.
234 2013-03-18 01:59:47 <gmaxwell> backing up the wallet.dat correctly e.g. via the backup function is what is necessary and sufficient, assuming you do it frequently enough.
235 2013-03-18 02:00:46 <swhitt> right
236 2013-03-18 02:00:52 <swhitt> but she has a ceramics stor
237 2013-03-18 02:00:53 <swhitt> e
238 2013-03-18 02:00:59 <swhitt> and she does 100 tx in 2-3 days
239 2013-03-18 02:01:18 <swhitt> I guess it's only an issue if she does outgoing tx
240 2013-03-18 02:01:30 <sipa> or generates a new address
241 2013-03-18 02:01:40 <sipa> which you should do for every incoming transaction :)
242 2013-03-18 02:03:10 <swhitt> well that increases the barrier to acceptance too
243 2013-03-18 02:03:19 <swhitt> she was thinking of just putting a QR code on the counter
244 2013-03-18 02:03:21 <swhitt> i dunno
245 2013-03-18 02:03:30 <swhitt> I suppose I could symlink the wallet.dat to dropbox
246 2013-03-18 02:03:35 <swhitt> and just have dropbox handle the backup
247 2013-03-18 02:07:19 <gmaxwell> swhitt: you can't just get copies of it when running, well you can of course, but if you do that many of the the backups will be unreadable.
248 2013-03-18 02:07:33 <swhitt> gmaxwell: is there an easy way to automate this sort of thing?