--- Log opened Fri Nov 01 00:00:21 2013
00:04 < warren> amiller: what are the groupings, IP address?
00:04 < amiller> no, mutual connectivity
00:07 < Luke-Jr> amiller: pools?
00:07 < Luke-Jr> how'd you make a map anyway?
00:29 < warren> <gmaxwell> e.g. software is still basically unusable for many OSX users.
00:29 < warren> gmaxwell: what makes it unusable?
00:33 < BlueMatt> leveldb instabilities
00:33 < warren> beyond the two fsync patches and leveldb 1.13?
00:34 < BlueMatt> <gmaxwell> There are more fixes than in 0.8.5 but not enough apparently.
00:34 < BlueMatt> <gmaxwell> If it had been confirmed they worked I'd have backported and we could have done a 0.8.6.
00:36 < warren> the 2nd fsync patch we confirmed wasn't enough
00:36 < warren> I have builds of both patches and leveldb 1.13 out now
00:36 < warren> no reports yet
00:36 < warren> nobody near me is able to reproduce the bug
00:36 < BlueMatt> so you're saying we should do another 0.8.X soon...
00:37 < warren> BlueMatt: only if it's confirmed to fix it, whch we don't know.
00:37 < Luke-Jr> ^
00:37 < BlueMatt> warren: you just said no one has yet been able to reproduce a semi-reproduceable bug with the latest patches, no?
00:37 < BlueMatt> at least that gives confidence that we should release builds to get more testing
00:38 < warren> BlueMatt: I mean nobody near me is able to reproduce the original problem, so I cna't get htem to test the builds that might fix it.
00:38 < Luke-Jr> BlueMatt: I think he means we don't know anyone who could ever reproduce it
00:38 < BlueMatt> (even if that just means telling people to try this alpha build)
00:38 < BlueMatt> ahh, ok
00:38 < warren> BlueMatt: I have been releasing builds
00:38 < warren> both litecoin and bitcoin users are complaining about this
00:38 < BlueMatt> for some reason I thought it was reproduceable by some set of people
00:38 < Luke-Jr> BlueMatt: it is, but nobody we know
00:38 < Luke-Jr> lol
00:38 < warren> jgarzik's office mate, toffoo on github and two litecoin users who fail to respond.
00:39 < BlueMatt> Luke-Jr: well why are those people not on speed dial?
00:39 < Luke-Jr> warren: jgarzik's office mate should try it?
00:39 < warren> I have no idea who they are.
00:39 < BlueMatt> warren: ahh, well why is jgarzik not reporting back...
00:39 < warren> BlueMatt: he's quite busy lately
00:41 < Luke-Jr> .. why did someone make be32toh return a non-uint32_t type? :/
08:32 < warren> gmaxwell: BlueMatt: https://bitcointalk.org/index.php?topic=320695.msg3456344#msg3456344
08:32 < warren> includes both fsync patches and leveldb-1.13
09:28 < Luke-Jr> warren: Bitcoin OMG seems redundant?
09:28 < Luke-Jr> or I guess not since it's based on a stable release instead of git
09:36 < jgarzik> Luke-Jr, sounds a bit like bitcoin-next
09:45 < petertodd> BlueMatt: I kicked testnet-seed into submission, although it seems sipa's seeder code returns DNS results that still screw up some resolvers.
09:48 < Luke-Jr> jgarzik: well, bitcoin-next only includes ACK'd stuff; sounds like next-test, except that it's based on a stable version instead of latest git
10:18 < adam3us> seems like warren took the bitcoin fedora to bitcoin rhel/centos discussion and went for it :)
10:21 < adam3us> petertodd, gmaxwell, amiller: btw yesterday discussion about one-show signature (its a credential/ecash concept but works ofr ECDSA eg as : addr = H(r=kG,Q) then being only allowed to use the r in the addr)
10:23 < adam3us> petertodd, gmaxwell, amiller: with PoS, which seems like a potentially useful extra sybil defence, the miner has a PoS voting incentive to have all his balance on one coin; as that defines his PoS vote multiplier (reference to the txout), in that way single-show sig could be quite a discouragement
10:24 < adam3us> petertodd, gmaxwell, amiller: (recalling to reuse r=kG implies reusing k which reveals private key d if you sign two different messages via simultaneous equation, so users have an incentive to hunt for double-spends so they can race to cash them)
13:06 < BlueMatt> petertodd: fun...this is why mine are served off bind :)
14:10 < petertodd> BlueMatt: yeah, I'm thinking that's probably a better idea overall :(
15:03 < gmaxwell> petertodd: is it just AAAA records breaking them?
15:07 < petertodd> gmaxwell: doubt it, I've tried without AAAA and it still doesn't work
15:08 < petertodd> gmaxwell: go and complain about gavin's obvious security hole: https://github.com/bitcoin/bitcoin/pull/3185
15:08 < petertodd> (he allows anything in the reject message, even newlines! so you can fake a log entry)
15:16 < BlueMatt> petertodd: doesnt dig still complain about extra padding bytes or something?
15:17 < petertodd> BlueMatt: I haven't looked deeply, but yeah, it complains about something
15:32 < jrmithdobbs> can someone tell me what I'm missing to get this example to actually work? I'm using 7.6.3 and aeson 6.2.1: http://hackage.haskell.org/package/aeson-0.6.2.1/docs/Data-Aeson.html#g:5
15:32 < jrmithdobbs> erm wrong chan
15:32 < phantomcircuit> jrmithdobbs, yes you're using haskell
15:32 < jrmithdobbs> haskell is p awesome ;p
15:33 < phantomcircuit> petertodd, the maximum message size is 1MB
15:34 < petertodd> phantomcircuit: pretty sure it was 32MiB... 1MB would be problematic given blocks can be 1MB
15:35 < petertodd> aww... gavin fixed it :( I was going to have so much fun writing that the genesis block got re-orged into people's logs :(
15:35 < phantomcircuit> petertodd, im pretty sure it's 1MB
15:36 < petertodd> phantomcircuit: heh, how much do you want to bet?
15:40 < phantomcircuit> i stand corrected
15:40 < phantomcircuit> that's actually pretty huge
15:40 < petertodd> Yup, it's was also the original blocksize limit.
15:40 < petertodd> which makes me think satoshi hadn't planned for one at all...
15:44 < sipa> petertodd: gavin fixed what?
15:44 < midnightmagic> ^^ by the way, gavin, if you use as the freenode IRC server password your nickserv authentication details you don't get the changing host thing.
15:44 < petertodd> sipa: his original rejection message patch let an attacker put fake entries into your log file
15:45 < petertodd> sipa: didn't filter out newlines :/
15:45 < gavinandresen> midnightmagic: how do i "use the freenode IRC server password"
15:46 < gavinandresen> IRC passwords are still a mystery to me, is there a clear explanation of which password does what somewhere?
15:46 < midnightmagic> gavinandresen: One sec..
15:46 < MoALTz> midnightmagic: edit server, server password in xchat right?
15:47 < midnightmagic> Yes. The IRC server password. You construct it like so:   NickName:NickservPassword
15:47 < gavinandresen> midnightmagic: okey dokey.  What is the Username then?
15:47 < midnightmagic> http://freenode.net/faq.shtml
15:47 < midnightmagic> No username.  There should just be a password field.
15:48 < midnightmagic> http://freenode.net/faq.shtml#nicksetup  <-- there it is.
15:49 < midnightmagic> In plain irssi, for example, you would connect with: /connect chat.freenode.net 6667 mquin:uwhY8wgzWw22-zXs.M39p    or your deets in place of..
15:49 < midnightmagic> there you go. I think that did it.
15:50 < MoALTz> midnightmagic: what happens if your zombie hasn't disconnected yet?
15:50 < gavinandresen> mmm.  Colloquy UI is confusing, it gives me Username and Password for server connection
15:50 < midnightmagic> MoALTz: It's not foolproof. In the event of a netsplit I think something weird happens then.
15:50 < gavinandresen> … and isn't smart enough to do the nickname:password thing, I guess
15:50 < midnightmagic> nah it's a freenode-ism I think.
15:51 < gavinandresen> that was my mistake, then-- looking at IRC help instead of FREENODE help....
15:51 < midnightmagic> MoALTz: Also I don't know what happens with zombies..
15:52 < midnightmagic> gavinandresen: znc, the bouncer I use, also uses that style to authenticate individual users and log them in to a user session. In znc, the server configuration line just has something like this: 2610:150:2c68::d0:dab:1de5 +6697 midnightmagic:MyNickServPasswordItsALongOne
15:56 < warren> Luke-Jr: jgarzik: it is not only ACK'ed things, it tests not-yet-approved things if we think it's a good idea and we tested it.
15:58 < amiller> MyNickServPasswordItsALongOneAlsoHighEntropyEjKRUaOJPo
15:59 < phantomcircuit> gavinandresen, colloquy like most os x software makes it impossible
15:59 < warren> well crap, someone reports the OMG build still corrupts on macos x
16:00 < gavinandresen> warren: mmm.  I got corruption running git HEAD, so that doesn't surprise me
16:01 < petertodd> warren: sheesh, I ran a bitcoin node for months on a computer with such flaky ram I couldn't get firefox to work for more than an hour at a time and it never corrupted the blockchain once :/
16:01 < warren> gavinandresen: corrupted even after a clean shutdown of bitcoin?
16:02 < gavinandresen> warren: was probably a dirty shutdown
16:02 < petertodd> warren: maddening how some stupid fs sync crap has a bigger effect than that ram
16:04 < sipa> petertodd: i doubt the corruption problems we're seeing are related to flaky hardware
16:04 < sipa> or at least, some
16:05 < petertodd> sipa: exactly my point; hardware/os lying about syncing is more of a threat than the hardware not working at all
16:06 < warren> It isn't clear if the corruption is only on certain versions of the OS.
16:06 < warren> I've seen most reports on 10.8+
16:06 < warren> one report on 10.7
16:07 < warren> none on 10.6, which might mean nobody is using 10.6?
16:08 < petertodd> warren: any chance the people on 10.6 are using different hardware than 10.7? (dunno nuthin about macs myself)
16:08 < gavinandresen> warren: I'm running 10.7
16:09 < petertodd> FWIW I did a SSD write corruption test a few years back at work, and I did find a SSD drive brand that lied about data syncing, so it's quite possibly a hardware thing related to some choice Apple made.
16:11 < warren> indeed, some brands of SSD are notorious
16:13 < warren> gavinandresen: what hardware?  apple provided HD/SSD?
16:13 < warren> gavinandresen: FWIW, our mac dev and coblee have *never* experienced corruption
16:13 < petertodd> warren: yup, and sadly this could just be some choice Apple has made that's far from easy for us to deal with.
16:13 < gavinandresen> warren: I have no idea, I bought this mac used.  I got corruption on both the SSD and the spinning disk.
16:18 < warren> gavinandresen: at this point are we willing to post a bounty on this?  "Reproduce corruption on demand, explain why it is happening." and separately "provide a fix that passes bitcoin dev approval"?
16:18 < gavinandresen> warren: sure, if you're willing to hold the money and judge the 'approval' go for it
16:19 < petertodd> gavinandresen: re: relay first double spend, you relaying the whole double-spend tx?
16:19 < warren> gavinandresen: where can the money come from?  we can pledge some from our funds
16:20 < gavinandresen> petertodd: yes, relaying the first double-spend as if it were the first spend
16:20 < sipa> with a different message?
16:20 < petertodd> gavinandresen: what happens if the first double-spend was a 200byte tx, and the second a 100KiB tx?
16:21 < gavinandresen> petertodd: then 100,200 bytes get relayed across the network
16:21 < gavinandresen> … assuming that both pass the IsStandard tests.
16:21 < petertodd> ugly...
16:21 < gavinandresen> simple
16:22 < petertodd> 500x cheaper to DoS the network. OTOH I like how this makes it easy to do replace-by-fee.
16:22 < gavinandresen> sipa: what do you mean, "with a different message" ?  No, just a normal inv / tx
16:22 < gavinandresen> (inv / getdata / tx)
16:22 < sipa> hmm, but without taking it into the mempool
16:23 < gavinandresen> petertodd: 500x ???  You can broadcast 100K transactions now.  This will make it at most 2x times easier to try to DoS the network.
16:23 < sipa> i'm not sure it's advisable to relay a transaction we're not considering valid ourself
16:23 < petertodd> gavinandresen: No, 500x, because I'm only paying for the bandwidth of the 200 byte tx. (or actually, even smaller than that is possible)
16:23 < gavinandresen> sipa: right, does not go into the mempool
16:24 < gavinandresen> sipa: the whole point is to broadcast it so that accepting-payment-in-person merchants will see the invalid transaction and can react
16:24 < petertodd> gavinandresen: Probably not an issue in practice, because someone will do replace-by-fee mining, but then that kinda defeats the purpose in a way...
16:24 < sipa> gavinandresen: right, which is why i'd use a different message
16:25 < warren> gavinandresen: is the foundation willing to add funds to such a bounty?
16:25 < gavinandresen> sipa: that just complicates the code unnecessarily
16:25 < warren> we can ask for public donations too
16:25 < sipa> to 1) make it clear that we're not actually considering this one valid and 2) make old nodes ignore it
16:25 < sipa> then again, nothing prevents someone from taking a faketx message and broadcasting it as a t
16:25 < sipa> as a tx
16:26 < gavinandresen> sipa: exactly, the code you'd write is exactly the same
16:26 < petertodd> sipa: Interesting thought: I can use this to broadcast a replacement, and because it's a standard inv, any miner who didn't get it the first time for some reason, and doesn't have it in their mempool, will get the second one. If the second one is a higher fee, maybe this time they'll accept it!
16:27 < sipa> yes, it may have unintended replacement effects
16:27 < sipa> giving a double spend higher chances for being mined than before
16:27 < gavinandresen> again, the reason for doing this is 0-confirmation transactions for merchants monitoring the chain.
16:27 < sipa> that's why i'd prefer not doing it the same way
16:27 < gavinandresen> err.. monitoring the network....
16:27 < sipa> i'm pretty sure it will lead to double-spends becoming easier :)
16:28 < gavinandresen> Easier-but-easier-to-detect is fine
16:28 < petertodd> sipa: Yeah, e.g. it makes it even easier to double-spend by broadcasting a, say, satoshidice tx, then waiting for my reply, then broadcasting a double-spend that doesn't involve satoshidice - I havea 10% chance of it getting mined by eligius without even needing to contact them directly.
16:28 < petertodd> Heh, funny thing I'm definitely going to ACK that patch because it's a step towards replace-by-fee and pure-profit-driven mining.
16:29 < sipa> petertodd: i'm in the middle about that, but imho the client should try to get peers to do the same
16:29 < sipa> so if you're doing replace-by-fee, i'm perfectly fine with it being the same tx message
16:29 < petertodd> sipa: get peers to what exactly?
16:30 < petertodd> sipa: ah, yeah, replace-by-fee would definitely use the same tx message
16:30 < gavinandresen> sipa: 0-confirmation double spends are pretty easy today.  I'm completely convinced early detection is more important than trying to prevent them.
16:30 < sipa> but if you're explicitly not considering a transaction valid, i don't like making it seem to others that you do
16:30 < sipa> gavinandresen: fair enough, i agree there
16:30 < gavinandresen> Lets debate replace-by-fee separately...
16:31 < warren> crap, two reports of corruption after a clean shutdown...
16:31 < warren> this makes no sense
16:31 < petertodd> gavinandresen: Well, the beauty of this is it lets miners decide for themselves given they now can easily get the replacement with no effort.
16:31 < gavinandresen> sipa:  double-spends are weird, though:  they're not really "invalid", just "I saw this one first"
16:32 < gavinandresen> (0-conf double spends)
16:32 < petertodd> Yeah, and it's hard to say which one was first anyway; what matters is that two exist.
16:33 < gavinandresen> sipa: Also: only double-spends of another 0-conf transaction will get sent; once a transaction is mined and the TxOut isn't in the UTXO, a double-spend will just get dropped.
16:33 < sipa> it's not even detectable as a double spend at that point
16:33 < gavinandresen> sipa: right
16:34 < phantomcircuit> warren, has anybody tried disabling the write cache on their hdd and seeing if that fixes it?
16:34 < warren> phantomcircuit: I personally got my first mac yesterday.
16:34 < petertodd> gavinandresen: this will make it easier to get tx's into people's wallets where a different double spend was actually mined; what's your thinking on fixing the 'never-will-confirm' tx's that'll show up in people's wallets?
16:34 < warren> I don't know how to do that.
16:34 < gavinandresen> phantomcircuit: reproducing it is the problem
16:34 < phantomcircuit> i can definitely see drives sold with apple hardware lying about the write cache being flushed
16:34 < phantomcircuit> gavinandresen, yeah it's a several month experiment
16:35 < gavinandresen> petertodd: that's just a bug that should be fixed.
16:35 < BlueMatt> petertodd: let other wallets that are smarter fix it :)
16:35 < warren> gavinandresen: is the foundation willing to pledge funds to this?
16:35 < BlueMatt> let bitcoind's wallet die
16:35 < phantomcircuit> my first guess is that the hdds apple uses are tuned to lie their asses off
16:35 < petertodd> BlueMatt: ha, some of them have IIRC
16:35 < warren> we've wasted a great deal of time failing to figure this out
16:35 < BlueMatt> yes, bitcoinj handles it very well
16:35 < gavinandresen> warren: foundation isn't, but I still have donated bitcoins for testing I'd be willing to pledge.  Say 5 BTC ?
16:35 < petertodd> BlueMatt: oh good! replacement for fees would trigger that one a lot
16:36 < BlueMatt> petertodd: well if replacement for fees ever gets enabled...
16:36 < warren> gavinandresen: that's a start, I'll try to find someone else to administrate the money holding
16:36 < petertodd> BlueMatt: heh, only needs epsilon hashing power for some value of epsilon to become an issue :P
16:37 < petertodd> BlueMatt: I mean, it annoyed me when I originally wrote the code...
16:38 < gavinandresen> warren: getting money from the foundation means going through the grant process, I don't want there to be a special "Bitcoin-Qt gets whatever it likes, other wallet/implementations have to jump through hoops"
16:38 < BlueMatt> petertodd: if replace by fee gets enabled, bitcoinj would get lots of transactions marked DEAD, I think, but it would be smart about it
16:38 < gavinandresen> too much confusion about relationship between the Foundation and the reference implementation already
16:38 < BlueMatt> unlike bitcoind's wallet...
16:39 < gavinandresen> "patches welcome"  :  as long as they come with a good test plan.
16:40 < petertodd> BlueMatt: that's plenty good enough for now - tx replacement is mainly useful because fee estimates will never be perfect after all. (modulo complex scorched earth game theory stuff)
16:48 < petertodd> gavinandresen: min standard tx size is ~134 bytes, 100,000/134=746 times cheaper to bandwidth DoS the network.
16:50 < petertodd> though $4/MiB is probably something we can live with...
16:51 < petertodd> wait, doh, no that's $0.04/MiB
16:51 < gavinandresen> petertodd: I'm still not following you.  Today, I can send 134 bytes to a peer and get 746 times leverage in terms of DoS bandwidth amplification.  Right?
16:51 < gavinandresen> petertodd: today, I can do that once for each UTXO I own in the UTXO set (assuming I'm willing to pay fees)
16:52 < petertodd> gavinandresen: My point is it's 746 times cheaper to do that, because you only pay the fees for the 134 bytes, rather than 100KB
16:52 < gavinandresen> petertodd: if first-double-spend is pulled, I can do that two times for each UTXO I own.  So the delta increase is 2, not 746.
16:52 < gavinandresen> cheaper to do it than what?  Than a world in which I cannot transmit any transactions?
16:53 < petertodd> gavinandresen: It's really simple: if I want to DoS the network now, I have to pay fees to do so, and I pay 0.1mBTC/KB or expensive priority.
16:53 < petertodd> gavinandresen: But with first-double-spend, I broadcast that 136 bytes tx first, then broadcast a 100KB double-spending tx, yet it's the ifrst one that is getting mined.
16:54 < petertodd> gavinandresen: Hence I'm paying ~750 times less for that bandwidth.
16:54 < gavinandresen> petertodd: 100KB won't be sent if it doesn't have enough fees-- MUST PASS ISSTANDARD CHECK
16:54 < petertodd> gavinandresen: But if the 100KB isn't mined, I didn't pay the fees!
16:55 < petertodd> gavinandresen: But if it is mined, then we've somehow enabled replace-by-fee basically...
16:55 < gavinandresen> Meh.  Might could be mined, depends on miner policies....
16:55 < petertodd> I mean, first-double-spend is totally safe re: DoS attacks so long as replace-by-fee is enabled!
16:55 < gavinandresen> … and your luck on when miners enter/leave network...
16:56 < petertodd> Yeah, so real world, maybe with bad luck I'm down to 500x, which is still a big improvement.
16:56 < sipa> ideally, you'd have a small proof of double spend
16:56 < sipa> rather than broadcasting the whole transaction
16:57 < petertodd> sipa: which you can do, you just prove the signature, but that's a fair bit of code
16:57 < gavinandresen> ideally we have a generic active queue management for managing bandwidth
16:57 < sipa> gavinandresen: true, but that's a different problem
16:57 < gavinandresen> … so that 100K double-spend is simply de-prioritized.
16:57 < petertodd> gavinandresen: right, but then that means double-spend detection isn't reliable
16:58 < petertodd> gavinandresen: I just have to simultaneously flood that channel while I do my attack
16:58 < gavinandresen> petertodd: if the detection isn't reliable, then the mining isn't reliable, either, and that is just fine
16:58 < petertodd> gavinandresen: no, you're saying it's deproritized, while tx's go through, so mining is reliable
16:58 < petertodd> gavinandresen: if it isn't reliable, then my DoS attack *is* effective
16:58 < gavinandresen> if it is deprioritized in relaying then it won't get to miners
16:59 < gavinandresen> I am ignoring Finney attacks, they are not solved by first-double-spend-relay
16:59 < petertodd> gavinandresen: right, but the that still doesn't solve the "broadcast simultaneously at two points" problem
17:00 < gavinandresen> petertodd: ???
17:00 < gavinandresen> petertodd: attacker does what-- broadcast a 150 byte txn at one point, and a 100K txn at another?
17:00 < petertodd> gavinandresen: you're solving the problem where a merchant doesn't know if you've broadcast simultaneous double-spending transactions.
17:00 < petertodd> gavinandresen: No, attacker disables double-spend detection by flooding it, then in totally unrelated transactions does a double spend.
17:01 < gavinandresen> flooding what?
17:01 < petertodd> gavinandresen: flooding the channel for double-spend detection - you said you'd de-prioritize that information channel
17:01 < gavinandresen> no, I would de-prioritize large transactions in that channel
17:01 < petertodd> gavinandresen: yes, and that doesn't help, because my double-spend can be large
17:02 < gavinandresen> okey dokey.  If both spends are large, they will both (likely) not make it to merchants or miners.
17:02 < petertodd> but anyway, I don't get why I'm arguing because for my purposes I'd rather see the patch happen...
17:02 < gavinandresen> If one is large and one is small, the smaller is likely to be mined/seen by merchants.
17:37 < warren> gavinandresen: did 0.7 or earlier have any mac corruption like this?
17:37 < warren> or it started with leveldb?
17:37 < sipa> bdb had different corruption patterns
17:37 < warren> (I wasn't around back then.)
17:37 < warren> linux and windows corrupted equally?
17:38 < sipa> unsure
17:38 < gavinandresen> I don't remember OSX having more issues with bdb
17:39 < sipa> this may actually be a leveldb-on-osx problem
17:39 < warren> does any other software use leveldb on osx?
17:39 < gavinandresen> I haven't seen "OSX sucks for running a database server", either, which makes me suspet the issue is leveldb specific
17:40 < gavinandresen> Chrome uses leveldb on OSX, but with a very different usage pattern and I think they don't use the same os-specific code we're using
17:40 < sipa> indeed
17:40 < sipa> chrome has its own environment layer
17:41 < warren> I have a hunch, but I need to be able to reproduce the corruption to confirm it...
17:42 < gavinandresen> sipa: could we mitigate the problem by truncating the leveldb MANIFEST file up to a known-good point?  Or would that screw up the integrity of the UTXO set....
17:42 < sipa> gavinandresen: my guess it it's something with interaction between mmap'ed files and writing, or some synchronization barriers
17:43 < sipa> i doubt we trying to "fix" it outside of leveldb is the right way
17:43 < gavinandresen> sipa: I agree, not the right way, but if it prevents "re-download-the-entire-blockchain" 50% of the time it might be worth dong.
17:45 < warren> making the problem happen less often will increase the chance of never fixing it
17:47 < sipa> i hope you're not downloading the entire blockchain every time, but just use -reindex
17:47 < sipa> anyway, truncating the manifest will just reset you to a former state, right?
17:47 < warren> sipa: some mac users are reporting that -reindex doesn't fix their mac problem.  it's difficult to confirm ecause these people don't respond to follow up questions.
17:47 < sipa> if the sstables corresponding to that state have been deleted, there is a problem
17:47 < sipa> warren: then they have a hardware problem, i guess
17:48 < gavinandresen> sipa: right -reindex… I'm actually copying known-good copies of the chain to a second drive, and restore from there if I get corruption.
17:49 < gavinandresen> sipa: and right, truncating manifest should just get to a previous state, which is why I thought truncating it might be a quick-and-dirty way of mitigating the problem
17:50 < gavinandresen> I haven't looked to see if any other leveldb files were corrupted
17:51 < sipa> if you ever get a snapshot of a corrupted state, that would certainly be something useful to try
17:51 < sipa> increasingly truncating more off the manifest, and seeing whether you end up with something valid
17:51 < gavinandresen> I've got a couple of snapshots of corrupted state, will try at some point if the problem doesn't get fixed before it percolates up to the top of my TODO....
18:27 < Luke-Jr> warren: I was referring to bitcoin-next; that is only ACK'd things.
18:27 < Luke-Jr> warren: next-test tests everything
18:29 < warren> ok
18:29 < warren> Luke-Jr: I notice that you didn't try to merge watchonly
18:29 < warren> it goes kaboom
18:29 < Luke-Jr> warren: it didn't exist at the time either
18:30 < Luke-Jr> when autotools have stabilised I'll probably make a new next-test
18:30 < Luke-Jr> still a bit too buggy imo
18:39 < phantomcircuit> gavinandresen, i have actually regularly told people not to use os x for servers, but for security not integrity reasons
18:40 < BlueMatt> who uses osx as a server?
18:43 < warren> jgarzik: hmm, disablewallet=1 needs a GUI error message if someone tries it with bitcoin-qt
18:49 < phantomcircuit> BlueMatt, silly people
18:50 < BlueMatt> then again, I suppose some use windows as a server too, which is far worse...
18:58 < phantomcircuit> BlueMatt, prior to last year it was actually much better
18:58 < phantomcircuit> (the joke is apple discontinued x servers like last year or something)
20:02 < warren> gmaxwell: jgarzik: updated fedora 19 openssl http://wtogami.blogspot.com/2013/05/openssl-with-ecdsa-for-fedora-18.html
20:15 < warren> gmaxwell: shoot, I lost the IRC log about the desired forum features, could you please copy that for me?
--- Log closed Sat Nov 02 00:00:49 2013