--- Log opened Thu Oct 31 00:00:27 2013
--- Day changed Thu Oct 31 2013
02:47 < warren> hmm, I see next-test didn't integrate Coin Control and watch only either.
05:53 < HM2> hmm
05:53 < HM2> article floating around praising Satoshis choice of the k1 curve over r1
05:53 < HM2> currently top of HN
05:53 < HM2> I thought the parameters to r1 were selected deterministically
05:54 < HM2> oh well
06:06 < sipa> HM2: with a 20-byte seed
06:06 < sipa> making the whole deterministic part quite suspicious :)
06:11 < HM2> You'd think NIST would have revealed the seed in light of recent events
06:16 < sipa> the seed isn't secret
06:16 < sipa> it is just long
06:16 < sipa> meaning it can have been selected by a brute force search for vulnerable parameters
06:17 < HM2> why couldn't they have gone for the classic value of pi
06:19 < sipa> or the string "5" or something
06:21 < HM2> sipa, how's your secp256k1 project coming along?
06:21 < HM2> has it reached peak performance?
06:41 < sipa> haven't worked on it for a while
06:56 < warren> HM2: crazy litecoin users are using it
06:58 < HM2> good good
07:26 < adam3us> HM2: nist probably dont know the real seed its probably in an HSM at NSA
07:26 < adam3us> HM2: i think its basically confirmed that it was backedoored; werent some of hte snowden docs published or seen by schneier and greenwald including the internal project summary bragging of th successful backdooring of nist process
07:31 < HM2> There haven't actually been any proof that NIST standards have been backdoored.
07:31 < HM2> I think the NSA presentations made a very strong indication that that was the case
07:32 < HM2> even the EC based RNG that is 'backdoored' is only a 'could be' backdoor (which is enough not to use it)
07:32 < HM2> for all we know the private parameters used to seed that could be lost and not in the hands of the NSA
07:33 < HM2> at least as far as I'm aware
07:33 < HM2> it's hard to keep a aprised of all the revelations concisely.
07:33 < HM2> *apprised
07:34 < HM2> the NSA has no reason to brag about their capabilities though, so it's very likely everything is as feared
07:35 < adam3us> HM2: so basically as i understood it from skimming the news over time, the level of confirmation was there were internal nsa docs in the snowden trove, that were read as indicating yes ec dbrng was backdoored
07:36 < HM2> no, not exactly. it gave a year
07:36 < adam3us> HM2: and particularly as the design seemed very contrived, and the backdoor potential was identified by ferguson et al at microsoft and published some years back, thats pretty much the end of it
07:36 < HM2> and the EC RNG was released that year
07:37 < adam3us> HM2: how does that confirm or refute the strong indication that could is actually was (backdoored)?
07:37 < HM2> I'm not sure who the target audience for the slides released was
07:37 < HM2> if your target is politicians you might want to brag
07:37 < HM2> if your target is foreign ally agencies maybe you want to brag
07:38 < HM2> maybe not
07:38 < HM2> they were all very vague, sadly not a single specific cryptocapability has been leaked afaik
07:38 < adam3us> HM2: i think its internal, but there was seeming lots of internal bragging, as it is about vying for recognition and internal project funding and kudos etc
07:39 < HM2> right
07:39 < adam3us> HM2: snowden made some relatively specific statements about crypto capacities that are lacking - ie public key crypto is good, if no impl mistakes and no hw / sw backdoors
07:40 < adam3us> is this channel logged publicly.. i found a petertodd amazon hosted log fragment; is there a full log searchable?
07:40 < HM2> there was mention of a 'major breakthrough' a few years back that hinted at cracking capability
07:41 < HM2> no idea
07:41 < HM2> you should assume it's all logged and kept in my personal blockchain
07:42 < HM2> in order for me to quickly fake something you said 3 months ago, i'd need a computer the size of jupiter ;)
07:45 < adam3us> is warren hand here the warren togami founder of fedora?
07:45 < adam3us> seems potentially apt that he could start bitcoin staging - the fedora to bitcoins rhel/centos
07:46 < adam3us> (tho he seems attached to making litecoin work in that role at present)
07:46 < HM2> I don't know. They're all faceless ninjas to me.
07:48 < adam3us> i read some old wired article that mentioned charles lee, and that warren togami had stepped in as lead dev of litecoin... then it occurred to me, hey that probably was warren who was talking about litecoin dev speed and healthy competition to bitcoin pushing chnges into bitcoin indirectly yesteray :)
07:49 < adam3us> it'd be easy enough to fork litechoin and put hashcash-sha256^2 and more work but defined method to put in the 1:1 one way peg allowing bitcoin transfer in place of mining
07:50 < jgarzik_> adam3us, yes, warren == warren togami of Fedora.  He and I both worked at Red Hat on Fedora, too.
08:12 < adam3us> erm so patents - has anyone tried to think about a model for preventing/deterring bitcoin related startups from patenting obvious and core things?
08:14 < adam3us> starting to rear its really ugly head unfortunately and i am pissed; people may not know the history but crytpocurrency ecash was littered with mothballed patents stifling products - i personally know a solid biz ecash guy who was blocked from doing something chaum related due to that patent
08:14 < jgarzik_> adam3us, bitcoin is a laggard in this area
08:15 < adam3us> particularly when digicash went bankrupt the VC type investors sold the patents to a random big co infospace that sat n them until they expired
08:15 < jgarzik_> adam3us, coming from Linux, we were really proactive about registering trademarks and patents for open stuff, then donating those to a foundation, preemptively
08:16 < adam3us> jgarzik_: i was thinking the same, maybe bitcoin founation can do something lke the IBM anti-patent abuse pool
08:17 < adam3us> jgarzik: the patent pool could have teeth in that anyone who tries to assert a patent outside of the pool, is denied use of any patent in the pool; but free for everyone else
08:17 < jgarzik_> adam3us, http://www.openinventionnetwork.com gathers patents from many sources, licenses them royalty-free, and can be used for patent defense through Mutually Assured Destruction
08:18 < jgarzik_> MAD: company A and company B cross-license each other's patents.  If a violation occurs, the other party revokes the patents they licensed
08:18 < adam3us> jgarzik: good, ibm mad like approach (microsoft was scared of accidentally tripping on IBM mad which is a good sign that its a good approach)
08:18 < jgarzik_> works with patent pools too
08:18 < jgarzik_> IBM is a fscking patent behemoth
08:19 < jgarzik_> surprisingly they are pretty benevolent in the software patent space, compared to many others, even though they don't have to be
08:19 < adam3us> jgarzik: they also have some kind of MAD scheme going that microsoft were more scared of than GNU
08:19 < adam3us> jgarzik: so whether its bitcoin foundation or the open thing you mentioned, or IBM: my point is there are no bitcoin patents in an open pool
08:20 < adam3us> jgarzik: and the various bitcoin startups are probably right now creating a raft of them to be "defensive" which is actually lethal
08:21 < HM2> it's not really lethal
08:21 < adam3us> jgarzik_: as when some of them start to go under the VCs that care more about money than bitcoin will sell them to the highest bidder
08:21 < HM2> mutually ensured destruction generally works quite well
08:21 < adam3us> HM2: viz digicash history and infospace
08:21 < adam3us> HM2: yes but there is no MAD, and bitcoin foundation has no patents
08:22 < jgarzik_> for MAD to work, you have to have patents others want
08:22 < HM2> Isn't the foundation just a benevolent observor/advisor?
08:22 < adam3us> jgarzik_: i think its past time the foundation or someone suggest strongly to all the bitcoin startups that they form a MAD pool, to preclude their patents falling into the wrong hands if they go out of business
08:22 < HM2> It doesn't even own the trademark does it?
08:23 < jgarzik_> yeah TM is an issue too, though I think MagicalTux was working on getting the TM for community benefit
08:23 < adam3us> jgarzik_: bitcoinFOO startup may have a patent for "defensive" reasons, bt when it goes under and is sold to a patent troll, it becomes offensive ... good intentions of bitcoinFOO no longer count
08:23 < jgarzik_> adam3us, agreed
08:23 < HM2> the Linux Foundation springs to mind
08:24 < adam3us> jgarzik_: or imagine worse things; US government seizes patents from the foundation as part of a court judgement, and asserts patent to make bitcoin-qt infringing
08:25 < jgarzik_> adam3us, so unlikely it's not worth worrying about
08:25 < adam3us> jgarzik_: patents should be abolished, but until then a bitcoin MAD pool should be created and probably should be held by an international, mulit-jurisdictional entity
08:27 < adam3us> jgarzik_: debatable, weak point on my part; main point bitcoin community probaby defensively needs a MAD pool in the hands of someone trustworthy and aligned with the community; i cant say more probably but i expect anyone with involvement with a commercial bitcoin entity has seen moves to patent something "defensively"
08:27 < jgarzik_> adam3us, agreed
08:27 < jgarzik_> adam3us, agreed (RE abolished + MAD pool)
08:28 < HM2> I'd worry more about the trademark
08:28 < adam3us> jgarzik_: so me = crypto guy, who could chase that down in foundation terms and make it happen?
08:28 < jgarzik_> adam3us, patrick murck, maybe
08:28 < HM2> someone could just buy it up the TM and just stick the name on whatever centralised currency they wish
08:28 < HM2> buy up the*
08:29 < jgarzik_> adam3us, tell him I pointed you to http://www.openinventionnetwork.com as an example
08:29 < jgarzik_> HM2, well like patent's concept of prior art, there is a way to show TM land grabs by third parties
08:29 < adam3us> jgarzik_: maybe a topic for this xgbtc list - didnt accept the list invite yet
08:29 < HM2> sure
08:29 < jgarzik_> adam3us, never heard of xgbtc
08:31 < adam3us> jgarzik_: apparently it originally stood for ex-google btc list, but is some kind of invite only ? bitcoin list that some bitcoin bigwigs are lurking on , or so i was told and found via a fwded mail from that list, from someone who got htemselves onto it
08:31 < adam3us> jgarzik_: i am not so much a fan of closed/moderated/non-open lists myself - i was kind of irritated at the concept
08:31 < HM2> jgarzik_, you're obviously not a bigwig :P
08:31 < jgarzik_> obviously :)
08:31 < adam3us> jgarzik_: so my buddy charles said let me find the mail (his words)
08:33 < adam3us> jgarzik_: (and its ridiculous to me that something relatively closed coudl be formed to talk about bitcoin with any coverage without having folks like this irc chat as first invitees) thogh i even dislike elitist closed lists on principle
08:36 < adam3us> charles said "it is the who's who of btc so need to get you on it" i am guessing maybe a bunch of mostly ex-googlers plus some bitcoin startup bizdev/ceo types... i'll find out soon (what was fwded to me was some discussion about some kaminsky intel-cpu-only mining function idea)
08:38 < adam3us> the list gatekeeper is bendavenport@gmail.com if you're not someone who refuses to partipate in closed lists on principle (i'm largely of that mentality...)
08:40 < sipa> is any of the core devs on that list?
08:40 < sipa> i had never heard about it
08:42 < adam3us> sipa: i dont know whos on it, i have the list invite, but i didnt click on it yet ecause it sends email to your gmail acct if you fwd your email to gmail which is a nuisance because i dont read my gmail
08:42 < adam3us> sipa: i saw peter vessenes name in the thread
08:43 < adam3us> sipa: there is a way to avoid supposedly  that but its complicated involves editing gmail urls and stuff
08:43 < sipa> meh :)
08:44 < adam3us> sipa: yeah maybe its more a bitcoin angel/mba/bizdev club
08:44 < sipa> sounds like it
08:44 < adam3us> sipa: so they think they're the who's who but we think they're n00bs in suits
08:46 < sipa> loi
08:48 < adam3us> jgarzik_: have an email for this Patrick Murck guy? i found his linkedin profile only
08:49 < jgarzik_> adam3us, https://twitter.com/virtuallylaw on twitter, gotta search for other.  bug me in 12 hours, after coding session ;p
08:52 < adam3us> jgarzik: google name, @domain -> patrick@engagelegal.com
08:53 < adam3us> jgarzik_: brain dump about strong need for bitcoin MAD/defensive pool heading patricks way  :)
08:56 < adam3us> jgarzik_:  i get the brunt of patent shit as my day job is crypto consultant to multiple companies... every time I open my mouth i have to watch what i say or i nor anyone else will be able to use that idea again, have to minimize damage by pointing them at open, prior art ideas only - though that can be partially succesful as patents "innovation" doesnt mean what it means in english
09:02 < jgarzik_> adam3us, patrick@bitcoinfoundation.org
09:18 < adam3us> btw about patents, i dont mean to imply any reason to doubt sincerity of the defensive motivation for bitcoin startups to apply for patents; just that history has shown it is not uncommon for such patents within 5-10 year in the normal chance of small companies going bankrupt and their investors selling the assets
09:40 < adam3us> is it matonis@btcf also?
12:03 < adam3us> amiller: about second ZKP there is a technique called limited-show which can prevent showing more than n times (eg more than 1 time) on pain of disclosing your private key via simultaneous equation if you do
12:06 < adam3us> amiller: the way to do that is restrict the owner to using only one initial witness, if he uses two different ones his private key can be calculated for analogous reasons to reusing k in DSA
12:06 < adam3us> amiller: its decribed in the extended schnorr context in http://cypherspace.org/credlib/brands-technical.pdf p23
12:33 < adam3us> amiller: for example in relation to dsa, that means r=g^k becomes part of the public key, and you're only allowed to use r by definition (not r'=g^k' for any other k'), eg say bitcoin address was H(r=kG,Q)
12:34 < adam3us> amiller: then, as bitcoin anyway always spends the entire input, bitcoin addresses could be strictly one-use, and if you double-spend you reveal your private key, to all miners, who take your coin for themselves instead of mining it - a crypto way to deter double-spending :)
12:35 < gmaxwell> adam3us: unless you're a miner, win win.
12:35 < adam3us> amiller: (of course you cant use that address to control multiple transactions, or you have a problem
12:36 < adam3us> gmaxwell: yes - i suppose the point is it may make certain kinds of bribe other miners to block competing transactions untenable
12:36 < adam3us> gmaxwell: its always going to be more profitable for them to take your coin rather than your bribe
12:38 < adam3us> gmaxwell: i mean then instead of it being plausible to send spend one to victim, and spend2 to some miners, or try to segment the entwork via network hacking or bribe to not-mine, double-spending becomes risky: anyone and everyone is on the hunt for double-spent transactions, because to a miner they are 100% fee :)
12:43 < petertodd> adam3us: meh, we've already got a way to deter double-spending: replace-by-fee scorched-earth. And it turns out double-spending is actually ver useful for a lot fo stuff.
12:47 < adam3us> petertodd, gmaxwell: could probably extend that to one spend per txout without having single use keys.  eg put r=kG in the txout but reuse Q
12:49 < adam3us> petertodd, gmaxwell: then a double spend of any of them allows all balance by any txouts controlled by that key to be cashed by miners
12:50 < petertodd> yeah, you could do lots of things, but double-spends aren't such a bad thing! there's no good way to resubmit a transaction if you don't allow them.
12:51 < adam3us> petertodd: well the reason i like looking at the double-spend mechanism is it is the core of the mining entanglement in the overall design - if there were  a way to do it without mining validation that could be a component of a scalability improvement
12:52 < petertodd> adam3us: why do you say it's the core of the mining entanglement?
12:53 < amiller> it would matter for a different network
12:53 < adam3us> petertodd: well to guarantee order is defined is why there is a single chain partly
12:53 < amiller> if we had like subchains that we wanted to merge
12:53 < amiller> in order to support higher transaction volume without making everyone have to hear them all
12:53 < amiller> then it would be useful to have ways of discouraging noncommutativity
12:53 < amiller> i.e. doublespends
12:53 < amiller> hardly matters for now though
12:54 < petertodd> right, but I think I solved that pretty decently the other day :)
12:54 < petertodd> (FWIW I'm halfway through writing up all that in a semi-proper paper)
13:02 < adam3us> amiller: so constitutional enforcement attached to sigs: single-show (as above), signature of knowledge (and the transaction) that either you know the discrete log of Q or currentReward() != blockreward
13:03 < adam3us> amiller: however i dont think it quite works, probably someone can make a 2 stage soft-fork to remove such checks from majority of clients, if they want to revise the constitution, an most of the users agree
13:04 < adam3us> petertodd: didnt the discussion get to sharding and trie representations within the shard, but still have to somehow avoid hashrate dillution weakening mining vote
13:05 < adam3us> petertodd: you did say something about that but i didnt understand it at the time and channel history gone
13:06 < petertodd> adam3us: I'll send you my logs
13:07 < petertodd> adam3us: but yeah, so basically *if* the blockchain data gets published by miners, it all works out and the hashrate dillution isn't a big deal: the resistance to changing historic data is still there, and because there's no validation required in the scheme that's much less of an issue
13:08 < petertodd> The problem is sharding inherently makes it easy to not publish that data, and essentially have the rest of the hashing power build upon state changes that only you can prove.
13:10 < petertodd> One approach there is to basically say "It's everyone's job to mine"
13:10 < petertodd> (if you withhold your block data, and don't have a local hashing power majority, the non-withholders will overtake you)
13:26 < adam3us> petertodd: maybe it can work, security for individual coins doesnt depend on cross shard mining, because their double-spend information is definitionally in the same trie-shard.
13:26 < adam3us> petertodd: additionally because we dont care which version of history is recorded, just that one is, the other shards can just hash the top of the other shard-chains best effort with out looking at or validating the contents of it
13:27 < petertodd> adam3us: yeah, I'm pretty much at the point where I think that in terms of resistance to rewrite, you just need timestamping, and that's what "cross shard hashing" is doing
13:27 < adam3us> petertodd: yes
13:27 < petertodd> It's the incentives to actually distribute the data that's ugly, and the resistance to rewrite can be a bad thing if someone does a 51% attack with the intention of destroying the data later.
13:28 < adam3us> petertodd: because you dont care what they said in their timestamp output, you're just preventing htem changing their mind later
13:28 < petertodd> yup
13:29 < adam3us> petertodd: you could even make a k-ary tree of time-stamp servers rather than a broadcast network of them, i think same principle applies
13:29 < petertodd> So one thing that can help, is for mining to be strongly coupled to the blockchain data: make a pow solution involve a non-interactive selection of some of the data, and make it only valid if that data is attached.
13:30 < adam3us> petertodd: well presumably at least the miners can validate the size of the pow on the shard mined blocks they include
13:30 < adam3us> petertodd: isnt that enough
13:31 < petertodd> Right, but the issue is a 51% attack against some subset of the blockchain data.
13:31 < petertodd> Like, if other miners *didn't* build upon your part of the blockchain via timestamping, this wouldn't be a big deal.
13:33 < adam3us> petertodd: yes its another aspect of the one-true chain model (must be up to 7 dependencies by now) it ensures that once your block is burried even one block other miners have an incentive to mine it ot avoid being orphaned
13:34 < petertodd> Yup
13:34 < adam3us> petertodd: i think i had the analgous problem you are talking about with complex incentives for the "thicket" of block chains approach
13:35 < petertodd> Sure, although I think the biggest issue is just the really fundemental one about how you need to be sure the blockchain data is in the hands of more than one person.
13:35 < adam3us> petertodd: at that time i concluded it was enough alone to kill it - simplicity is good etc but this variant has additional advantages so maybe we can still get back to a net win eventually
13:36 < petertodd> Yup. Like, suppose we could make the assumption that the majority of hashing power would be mining all shards in one go, then that majority would have the data, and there'd be no issue at all. But we can't assume that.
13:36 < adam3us> petertodd: its not inherently interesting to someone to censor your shared block hash, they have to want to present a different version of it with a different spend
13:36 < adam3us> petertodd: right - thats the 7th dependency - super-entangled design when you get to all of the dependenices
13:36 < petertodd> Economically interesting no, but if their goal is to destroy the system then you're in trouble.
13:37 < adam3us> petertodd: yes, and you have defend against that
13:37 < petertodd> Yup. I dunno, maybe it's the case that fundementally you can't? But I'd sure hope you could at least do better.
13:37 < adam3us> petertodd: in my thicket thought experiment (unpublished) i was supposing some modest reward bonus for being the first to pull in a shard-hash
13:38 < petertodd> what do you mean by "pull in"?
13:38 < adam3us> petertodd: or a share of the fees in it (hash it as an input another shard hash)
13:39 < adam3us> petertodd: i think you need to have some list or merkle hash of shard-hashes so that as time-progresses each hashed block includes everything else if you explore down the tree a bit
13:40 < petertodd> See, my thought experiement is a little different: for a given committed transaction input, we should be able to calculate the total work done by all miners with that transaction input in their dataset. (assuming the pow scheme does proof-of-data)
13:40 < adam3us> petertodd: (each shard-hash includes all other shard hashes in a best effort sense, motivated by a share of the fee and/or reward)
13:41 < petertodd> Yeah, although maybe at this point it'd be better to leave reward out; I think in a inflationary system we can reward people simply by taking their coins away unless they mine in porportion to the coins they own.
13:44 < adam3us> random non-tech thought about the "what is bitcoin" virtual commodity, etc .. its a crypto/math geeks stamp collection
13:44 < petertodd> heh
13:45 < adam3us> see in hashcash in the mail context they were stamps and i have a page with a stamp collection; they are rare because they ar eexpensive, and a math/crypto/computer geek can admire and appreciate the beauty (or waste) in finding a number with 15 leading 0 hex digits so they have math aesthic value too
13:46 < adam3us> http://hashcash.org/stamps/ one of those was 48 bits eve years ago
13:46 < petertodd> yeah, bitcoin is special in figuring out how to take those stamps and assign them owners with global consensus
13:46 < petertodd> heh, meanwhile we've got, what, 68 zero sha256^2 pre-images now?
13:46 < adam3us> right; it wouldve been easy to give a hashcash a public key, just include a pub key in the hash (as bitcoin does), and i thought about it for mail apps even (prove a reputation)
13:47 < adam3us> yes
13:48 < adam3us> actually i calculated it here: https://en.bitcoin.it/wiki/Hashcash
13:48 < adam3us> its 60.6 bits right now
13:48 < adam3us> or 61.6 bits of security (there are 2 hashes per try so +1)
13:48 < adam3us> more secure than 56-bit DES :)
13:48 < petertodd> ha
13:50 < gmaxwell> adam3us: well I don't think you get to count the ^2 ... I mean, sha256 is much slower in hardware than DES and you're not counting that.
13:50 < adam3us> the guy etienne gervais wrote his own openCL hashcash-sha1 miner just to get leaderboard on that page :)
13:50 < petertodd> Interesting thought: so, in my txin commitments scheme, what you need to keep "up-to-date" with, in terms of the blockchain, is the part of the blockchain with the still un-revealed txouts that your wallet contains. IE, the important part of the txin space is still "zeroed" up until you want to spend it to someone else.
13:50 < adam3us> gmaxwell: yes it is a question of what counts as an op in O(2^n) notation grey area
13:51 < petertodd> Not brilliant, but it is a bit of a security improvement in that targetting you specifically to make your coins unspendable is hard if you keep those txouts a secret.
13:51 < adam3us> gmaxwell: if it was computing DES unlike eff des cracker which computed one des decryption in 56hrs, bitcoin network can do it in < 12 sec
13:51 < gmaxwell> you could instead use some transistor toggle metric.
13:52 < adam3us> gmaxwell: vaguely recall knuth might've had some complexity metric based on a styled pseudo assembly code :) even with cycles or instructions depends on cisc, risc etc
13:53 < gmaxwell> adam3us: art's (who you didn't get to interact with, early bitcoiner who went away) fpga mining farm could do a full des search in ~24 hours and I think that was just a 40GH bitcoin farm.
13:54 < adam3us> gmaxwell: its interesting in that des cracker was built in 1998 for $250k but if it was sha256 instead of des it'd still be respectable and maybe profitable for bitcoin i think (have to check calc)
13:55 < gmaxwell> adam3us: DES is especially weird, becaues the sboxes yield especially compact combinitorial logic.
13:55 < adam3us> it was doing 280 TDes/sec
13:55 < adam3us> for $250k
13:59 < adam3us> gmaxwell:  something seems wrong… bitcoin hashrate = 3 ExaH/sec if deepcrack was 280, it'd be only 10x slower, but thats not true; yet 2^56/56/6/1000^4 = 280 hhmm (deepcrack could do 2^56 in 56hrs)
14:00 < adam3us> gmaxwell: oh bitcoin hash rate is now 4 Exah (33% increase as of a  few days) jeeze
14:10 < petertodd> adam3us: suppose we ensured that mining some portion of the blockchain required the consent of the majority of the owners of the coins in that portion, do you think the data hidng problem would be sufficiently solved?
14:10 < petertodd> (ignore practical difficulties here)
14:16 < sipa> adam3us: what is Exah?
14:16 < sipa> per what time?
14:17 < sipa> it's 3.8 petahash/s
14:17 < sipa> where hash = double-sha256
15:36 < HM2> Android has improved its security further by adding support for two more cryptographic algorithms. Elliptic Curve Digital Signature Algorithm (ECDSA) support has been added to the keystore provider improving security of digital signing, applicable to scenarios such as signing of an application or a data connection. The Scrypt key derivation function is implemented to protect the cryptographic keys used for full-disk encryption
15:36 < HM2> Android adopting Scrypt is pretty big crypto news I guess
15:40 < sipa> ooh nice
15:42 < HM2> yeah, not sure whether they make that available via the general crypto APIs
16:45 < adam3us> sipa: better that explains my error
17:19 < sipa> amiller: ?
17:19 < sipa> ah!
17:20 < amiller> haha, my phishing attack is complete
17:20  * gmaxwell is confused
17:20 < amiller> i'm approximately authenticated as adam back
17:20 < amiller> as far as sipa is concerned
17:21 < gmaxwell> Well, a people all look the same.
17:22 < sipa> my authentication scheme is based on H(nick[0])
17:42 < amiller> ugh question about colored coins again
17:42 < amiller> to determine if a txoutput has the color
17:42 < amiller> do you have to trace just a *path* through the transaction tree down to the genesis of the colored coin/
17:42 < amiller> or do you have to trace the whole tree?
17:43 < amiller> someone convinced me it was just the tree
17:43 < amiller> er just a path
17:43 < amiller> but now i think it's the entire tree, because you have to establish the color value of *every* txinput, which is then recursive
17:44 < gmaxwell> amiller: I'm not following the distinction. If you recieve a colored coin and someone tells you the respective genesises you can just connect them and ignore unrelated parts of the history.
17:44 < gmaxwell> I suspect most people flapping their lips about this stuff have never picked a random coin on the network and tried to extract its whole history.... :P
17:45 < gmaxwell> (it's pretty normal for something to be tainted against a singnificant fraction of all past transactions)
17:45 < amiller> what is the unrelated part of the history though?
17:45 < amiller> it would be nice if, for example, if i only cared about this current txout, then i have to look backwards to at most one txinput ineach transaction
17:45 < amiller> thus a linear path from the txout in question to the genesis
17:45 < gmaxwell> amiller: if you know which coins were the genesis you can trace forward and back and meet in the middle.
17:46 < gmaxwell> amiller: you only can do that if you already know the path (e.g. someone else already traced it)
17:46 < gmaxwell> if you know the genesis and the rule is setup right you can trace forward with one output per transaction.
17:46 < gmaxwell> but backwards alone is exponential.
17:47 < amiller> i don't see how to go forward with one txout per transaction
17:47 < amiller> can you recommend a link with code for this
17:47 < amiller> or a dsecription
17:47 < amiller> (or just elaborate here?)
17:47 < jrmithdobbs> gmaxwell: even with a pre-sorted map all historical txns in the chain?
17:47 < gmaxwell> amiller: because the colored coin rule says that the color goes into the first colored coins worth of txouts.
17:47 < amiller> so only one txinput can be colored?
17:48 < amiller> only splits no merges?
17:48 < jrmithdobbs> gmaxwell: and by 'the chain' i mean the blockchain, not the usage/history chain of those coins
17:48 < gmaxwell> amiller: TXOUT. I'm specifically saying tracing forward from the genesis, not backwards from the payment.
17:48 < jrmithdobbs> gmaxwell: it's getting more prohibitive but still feasible after all
17:48 < gmaxwell> and if you split then its the first N or whatever, and yea, you have to trace them all in the case of a split, thus why I mentioned meet in the middle.
17:48 < amiller> you mean i trace *all* the ones forward?
17:49 < amiller> i see
17:49 < gmaxwell> or you have someone just preidentify the paths and you just confirm them, which is fundimentally easier.
17:49 < amiller> yeah i'm just thinking of the ones needed to confirm
17:49 < gmaxwell> and I have no clue about code for this. As I said, most people talking about this crap have not implemented it and are missing how expensive this is.
17:50 < amiller> i wish i had some way to express this bound
17:50 < gmaxwell> some of the stuff that was implemented simply just keeps an enormous database and traces the color (according to their rules) of every coin.
17:50 < jrmithdobbs> it's only one of the most computationally expensive features ever requested
17:50 < amiller> that's what i first wrote down
17:50 < jrmithdobbs> I don't know that I really agree with the necessity of it
17:50 < amiller> it's the same as mastercoin in that case
17:50 < amiller> you get nothing like spv security
17:51 < amiller> you need to build the index for every coin that *might* interact with a coin later that you care about
17:51 < amiller> or else traverse a potentially exponential number of tx
17:51 < gmaxwell> yes, thats been one of the objections to all these stupid parasitic things. The network is blind to them, but the network is blind to them.
17:51 < sipa> i wish we hade pruning and spv in the reference client, so all these fancy-feature implementers would at least realize what they're precluding
17:52 < sipa> gmaxwell: the first member of tautology club...
17:52 < gmaxwell> after all, you could just have a bitcoin where the blocks were nothing but timestamps and miners didn't validate anything. ... of course you could never have any kind of lite node in that world except centeral server trusting ones.
17:53 < gmaxwell> sipa: don't worry we'll just <arms wave> use checkpoints to make our uber indexes scale! or we'll like, write those checkpoints into transactions so you can get them in the blockchain too.
17:53 < sipa> Easy.
17:53 < jrmithdobbs> gmaxwell: i just vomitted a little
17:54 < sipa> gmaxwell: if the indexes grt toobig, you use a DHT of course
17:54 < sipa> and rainbow tables
17:54 < sipa> *get too big
17:54 < jrmithdobbs> dht is my favorite of those
17:54 < jrmithdobbs> lol
17:55 < gmaxwell> yea, plus if that doesn't handle it we can use an xml database with ldap to haddoop to achieve webscale in the cloud!
17:55 < jrmithdobbs> there's no problems to solve with a massively distributed untrustworthy dht rite guys?
17:55 < amiller> grrr
17:55 < gavinandresen> rainbow tables are pretty
17:56 < jrmithdobbs> gmaxwell: and you could do elastic scaling pools of resque queues synchronized by a redis entry and just give up on this decentralized nonsense while we're at it
17:56 < amiller> colored coins definitely aren't fungible if some of them are potentially way more expensive to verify than others
17:56 < amiller> i'm annoyed if anyone really thinks that's preferable than the index approach
17:56 < amiller> if everyone has to keep an index then colored coin has no advantage over mastercoin
17:57 < gmaxwell> amiller: the index approach isn't cheap either, no spv nodes, just some gigantic index.
17:57 < amiller> yes
17:57 < gmaxwell> amiller: well mastercoin requires coding in a bunch of extra stupid data into transactions which seems kinda silly, since if you have to have that index why can't that index store it?
17:58 < amiller> not really, if it's published then you have a guaranteed ordering
17:59 < amiller> it is reasonable to use bitcoin as append only log in that sense
17:59 < gmaxwell> In any case, minus that detail they're actually the same thing, index vs trace being an "implementation detail", likewise the system depending on its own currency that the creators minted and manually issued is an implementation detail.
17:59 < gmaxwell> amiller: you can get guaranteed ordering from the hash of the state rather than coding it explicitly.
17:59 < amiller> no you can't
17:59 < amiller> because it's indeterminate whether the preimage of a hash has been revealed yet
18:01 < gmaxwell> amiller: makes it halariously vulnerable to censorship if they're counting on the blockchain as a jamming free communications channel.
18:01 < amiller> why?
18:02 < jrmithdobbs> amiller: because you can outbid them for space and delay their comms indefinitely under some circumstances
18:02 < amiller> that's no worse than with bitcoin proper
18:02 < gmaxwell> because they're trivially distinguishable.
18:03 < jrmithdobbs> amiller: right but bitcoin isn't trying to differentiate inputs like this so it doesn't matter, delaying the data distribution can effectively delay any affect from the color system decreasing it's value
18:03 < gmaxwell> It would be in the rational self interest of bitcoin users and miners to not allow the currency to be dilluted by the non-fungable mastercoin transactions which are trivially distinguishable.
18:03 < jrmithdobbs> amiller: if i can pull off a heist and delay coloring of my coins for 48 hours i can probably spend them
18:03 < jrmithdobbs> eg
18:04 < amiller> i see
18:04 < amiller> well... if you can delay blocks to full validating nodes... then
18:04 < amiller> i dunno i don't really see a conflict with requiring bitcoin to implement a jam free network sufficient to validate transactions
18:04 < amiller> you have to at least run the tx through the hasher
18:04 < amiller> you can prune it before validating etc
18:05 < jrmithdobbs> don't have to delay blocks just SD style spam with paid fees (what I'm talking about isn't free, I'm sure you could come up with more inventive similar attacks)
19:50  * Luke-Jr stabs Google for signing him up for G+ without permission
19:51 < gmaxwell> Luke-Jr: it's not all bad, ... now you can show up in ads endorsing products! and you didn't even have to go to a tryout!
19:51 < Luke-Jr> I don't want to be on G+
19:51 < MoALTz> accidentally clicked one button that did it all? microsoft did that to me a few years ago
19:51 < Luke-Jr> my only guess is when YouTube asked if they can put a space in my name "Luke Dashjr" instead of "LukeDashjr" when I left a comment
19:52 < gmaxwell> yea, youtube does that.
19:52 < Luke-Jr> didn't say I was joining G+
19:52 < Luke-Jr> -.-
19:52 < gmaxwell> you have to just not use youtube for 12 hours after it pops up that rename dialog.
19:52 < Luke-Jr> srsly?
19:53 < gmaxwell> yea, works for me. you can delete your google+ but it'll keep doing the thing after the fourth or fifth consecutive video you view.
19:55 < BlueMatt> or not comment on youtube videos?
19:55 < gmaxwell> BlueMatt: nah, it gets triggered even if you don't comment if you view a couple videos in a row
19:55 < BlueMatt> lol, wow...
19:57 < gmaxwell> It also helps to be in an office with a couple other google+ refuseniks... since you can share mechenisms for getting around it. though there seems to be no workaround for some things. E.g. no way to do hangouts.
19:57 < gmaxwell> so we have a sacrifical mac in the office for hangouts access that has its own dummy account.
19:57 < BlueMatt> or you could just have a dummy g+ account on your google account, its not like you have to use it
19:57 < BlueMatt> you just get counted as a g+ "active" user
20:01 < K1773R> there should just be a way to opt out...
20:10 < Luke-Jr> gmaxwell: therefore, discourage people from doing Hangouts
20:11 < Luke-Jr> gmaxwell: Google Apps which upgrade to Hangouts lose XMPP interoperability -.-
20:16 < jgarzik> Hangouts > Skype
20:16 < sipa> hangouts <-> XMPP works fine, as long as you don't do groupchats
20:16 < sipa> unsure about federation though
20:23 < gmaxwell> Luke-Jr: it's hard to discourage google employees from using hangouts. :P
20:30 < Luke-Jr> gmaxwell: "you won't be able to talk to me" works for me
20:30 < Luke-Jr> jgarzik: two bad choices don't make the lesser bad a good one
20:31 < Luke-Jr> there are open standards for all this; Google just doesn't care apparently
21:32 < jgarzik> XMPP is exceeding lame
21:33 < jgarzik> and I speak from experience, having coded solutions for it back when it was called Jabber
21:34 < jgarzik> It's hard to fault people for avoiding a lame standard
21:37 < Luke-Jr> jgarzik: it's better than none at all
21:38 < phantomcircuit> xmpp is pretty horrible
21:38 < jgarzik> http://gigaom.com/2011/06/30/google-hangouts-technology/
21:39 < jgarzik> I cannot find any open protocol docs, but it does use several open techs
21:39 < jgarzik> XMPP is not meant for real time multi stream audio+video
21:47 < BlueMatt> was there a bug in a recent satoshi client that allows it to forward vin empty txn?
21:48 < phantomcircuit> BlueMatt, yeah there is
21:48 < phantomcircuit> or was
21:48 < phantomcircuit> i cant remember if it was fixed
21:49 < Luke-Jr> jgarzik: SIP is
21:50 < jgarzik> phantomcircuit, not sure if it was fixed... I think it was tracked down to $something wound up writing an all-zeroes transaction to the wallet, or somesuch.
21:51 < phantomcircuit> jgarzik, oh i think i found it
21:51 < BlueMatt> jgarzik: Im seeing lots of dos bans going out on my testnet node as well as a few on my non-listening mainnet node...
21:51 < phantomcircuit> yeah i remember there's one place where mapWallet[] is used and it doesn't check that the transaction is actually in mapWallet
21:51 < gmaxwell> BlueMatt: are they nodes that are sending you empty vins?
21:51 < BlueMatt> gmaxwell: yes
21:52 < gmaxwell> I wish we knew what caused that. Best theory right now is that there is some wallet bug.
21:52 < BlueMatt> did petertodd fix his testnet dnsseed that was apparently broken?
21:52 < BlueMatt> gmaxwell: if only there was a way to message someone based on ip...
21:53 < gmaxwell> BlueMatt: we've actually talked to some people with it, and determined at least one of the people with it had a wallet with a empty transaction in it that it was rebroacasting.
21:53 < BlueMatt> ahh, fun
21:53 < BlueMatt> before I just restarted my node, I had two peers that were doing so (out of 8)
21:54 < BlueMatt> so it doesnt appear to be uncommon
21:59 < phantomcircuit> BlueMatt, in walletdb.cpp line ~240 the "tx" logic
21:59 < phantomcircuit> you can see that if the transaction is corrupted in anyway it will be erased from mapWallet
22:00 < phantomcircuit> im guessing there is something else that fails to check that a tx is in mapWallet before accessing it
22:00 < phantomcircuit> and thus creates a default tx
22:00 < phantomcircuit> which has an empty vin
22:01 < gmaxwell> but then how does that get saved?
22:01 < BlueMatt> maybe its not?
22:01 < gmaxwell> no, I think we know it got saved (e.g. got a wallet file from someone expirencing it)
22:02 < BlueMatt> ok
22:02 < gmaxwell> though perhaps I should grep my logs to be sure.
22:02 < BlueMatt> did you get the actual wallet file, or just reports?
22:02 < phantomcircuit> gmaxwell, when the wallet was flushed all the values in mapWallet are blindly updated i think
22:03 < gmaxwell> BlueMatt: I think sipa got an actual wallet file, but I could be misremembering.
22:03 < phantomcircuit> for example wallet.cpp if(!ExtractDestination(mapWallet[txin.prevout.hash].vout[txin.prevout.n].scriptPubKey, address))
22:04 < phantomcircuit> that would add a default CTransaction if txin.prevous.hash isn't in the wallet
22:05 < BlueMatt> did anyone file an issue for this?
22:05 < phantomcircuit> BlueMatt, no idea
22:05  * BlueMatt doesnt see one, creating
22:05 < gmaxwell> phantomcircuit: hehe. I bet I added that.
22:06 < phantomcircuit> when i was looking at vtxprev i realized that a bunch of the tx records in the wallet are just the default ctor
22:06 < phantomcircuit> and all the vtxprev values are
22:06 < phantomcircuit> 10254401 (Pieter Wuille            2012-05-14 23:44:52 +0200  603)     if (ExtractDestination(txout.scriptPubKey, address) && ::IsMine(*this, address))
22:06 < phantomcircuit> sipa, ^
22:06 < phantomcircuit> :)
22:06 < phantomcircuit> fortunately the wallet code is very robust against that type of failure
22:06 < phantomcircuit> so it's not a big deal
22:06 < gmaxwell> yea, well, we're relaying empty txn and our peers disconnect us for that.
22:07 < BlueMatt> should I pull-request a commit to fix
22:07 < BlueMatt> https://github.com/bitcoin/bitcoin/issues/3190
22:07 < gmaxwell> I still don't see how adding empty txn in map wallet should result in that.
22:07 < BlueMatt> oops
22:07 < phantomcircuit> gmaxwell, iirc the resend logic is really simple, it's just, if (tx not confirmed) {send tx}
22:08 < phantomcircuit> it doesn't try to determine whether it's a double spend or invalid or anything
22:08 < BlueMatt> the wallet relay logic specifically prevents the tx from getting verified before relay iirc
22:08 < gmaxwell> yea, we need to improve that generally, as it super highly identifies nodes.
22:08 < BlueMatt> (though somehow I remember removing that and getting it merged, but I dunno)
22:09 < gmaxwell> e.g. if someone sends you an invalid double spend, they're probably the source of the txn.
22:09 < gmaxwell> Or you mutate someone's transaction and then their node will continue to beacon the invalid duplicate forever.
22:09 < phantomcircuit> gmaxwell, or they're the recipient and are the victim
22:09 < gmaxwell> (in fact, the wallet on my laptop is currently doing that)
22:09 < phantomcircuit> either way it means the tx is in their wallet
22:10 < phantomcircuit> brb stealing candy
22:10 < gmaxwell> (because I spent some anyone can spend garbage txn and someone beat me in the race)
22:11 < BlueMatt> phantomcircuit: really? leave the kids alone
22:12 < phantomcircuit> BlueMatt, im taking it from my neighbor
22:12 < gmaxwell> hm actually I have free confirmation 0 txn in my laptop wallet.
22:12 < BlueMatt> is it just me or is 0.8.1 very popular?
22:12 < BlueMatt> is that the version before dust or so?
22:13 < gmaxwell> ah, orphan blocks. :)
22:13 < phantomcircuit> BlueMatt, it's the version which made a significant improvement in performance enough that people stopped noticing
22:13 < gmaxwell> BlueMatt: it's very popular because its what fixed the hardfork 0.8 bug.
22:13 < gmaxwell> 0.8 people moved to for performance, and 0.8.1 people moved to because zomg hardfork.
22:14 < BlueMatt> ahh, and then never upgraded beyond then
22:14 < gmaxwell> If it bothers you, you could resolve that issue with four lines of python ... :(
22:14 < gmaxwell> (it's trivial to crash pre 0.8.4)
22:14 < BlueMatt> wasnt there a security issue or two fixed
22:14 < BlueMatt> yea...thought so...
22:14 < amiller> we did our first run of the entire network connectivity mapper today
22:14 < gmaxwell> double plus if you get a negative nversion txn mined just before, then they won't come back.
22:14 < BlueMatt> you can thank me for that :)
22:14 < amiller> hopefully no one has noticed any weird or hamrful transaction patterns
22:14 < phantomcircuit> gmaxwell, the hard part is actually getting a list of active nodes
22:14 < phantomcircuit> heh
22:15 < gmaxwell> amiller: someone was complaining about their node crashing earlier in #eligius, but I assum it's unrelated.
22:15 < phantomcircuit> amiller, whatcha doin
22:15 < gmaxwell> phantomcircuit: luke provides one.
22:15 < amiller> phantomcircuit, i told you a while ago about the first version of our connectivity tester, it's matured a bit since hten
22:15 < phantomcircuit> ah
22:16 < phantomcircuit> hmm
22:16 < amiller> but basically we want to go through every pair of nodes we can connect to and determine whether they're connected
22:16 < amiller> (or, whether they're connected via a single other node we can't connect to)
22:16 < phantomcircuit> i'd release mine but it's got a bunch of unrelated attack code in it
22:16 < phantomcircuit> too much effort to sanitize
22:16 < gmaxwell> amiller: can you estimate the size of the network you can't connect to?
22:17 < amiller> we could if the kid who is running this did what i asked but i'm not adminning any system to do so
22:17  * BlueMatt ponders the ethicacy of pointing one entry in dnsseed to a amiller-scanning node so they get lots of incoming connections too
22:17 < amiller> basically that would just involve having a bunch of long standing nodes
22:17 < gmaxwell> like, we know the size of the connectable network is frighteningly low, but I have hope that the unconnectable network is reasonably large.
22:17 < gmaxwell> BlueMatt: please never do something like that.
22:17 < BlueMatt> thought so
22:17 < amiller> we've estimated it's 30k which matches what everyone says but it's not a great kind of estimate
22:17 < phantomcircuit> amiller, how can you do that beyond just counting incoming connections and extrapolating?
22:17 < amiller> phantomcircuit, yes that's all we can do
22:18 < BlueMatt> gmaxwell: well, for testnet my "dnsseed" is a static list of {my desktop}
22:18 < gmaxwell> BlueMatt: about the furtherst I'd go is twiddling to get load on a node for development testing.
22:18 < amiller> the best way to do it would be with planetlab or something, start a bunch of nodes and keep them up a lot
22:18 < phantomcircuit> amiller, then it's basically 4 * 30
22:18 < phantomcircuit> thousand
22:18 < gmaxwell> oh well testnet I don't give a shit about, do whatever with that. :P
22:18 < amiller> the more nodes you have up you can infer
22:18 < phantomcircuit> oh /8
22:18 < phantomcircuit> so ~15k
22:18 < amiller> what i want to do is find the smallest cut
22:18 < BlueMatt> gmaxwell: yea, Ive never even done that, nor do I plan on it
22:18 < phantomcircuit> unless the number of connections a listening nodes gets has changed significantly
22:18 < amiller> the smallest number of public nodes needed to crash to actually partition the network
22:18 < amiller> or various other metrics i dunno
22:18 < BlueMatt> oh, no, thats a lie, I wanted to crash my node once to debug a memory issue
22:19 < BlueMatt> well, thats all Ive done
22:19 < amiller> really the point is just that the technique for probing connections is really clever
22:19 < gmaxwell> BlueMatt: yea, I recall you doing that for load, I think thats fine.
22:19  * BlueMatt offers node-crashing service for devs who need it :p
22:19 < phantomcircuit> amiller, the question is what % of the network you need to crash to partition some other % of the network
22:19 < gmaxwell> BlueMatt: esp since if you give bad dns data to bitcoinj nodes its trivial to partition them entirely. :(
22:19 < phantomcircuit> the 500ms connect() timeout should probably be increased actually
22:19 < phantomcircuit> the more i think about that the more i think 3000ms is safer
22:20 < gmaxwell> phantomcircuit: it's high for tor, but making it high has other problems.
22:20 < BlueMatt> gmaxwell: heh, yea, there was a bug the other day that the other testnet dnsseed was down and I was moving my server, so they were stuck unable to connect
22:20 < phantomcircuit> gmaxwell, yeah but im saying to make it even higher
22:20 < phantomcircuit> since at 500ms there are some people who wont be able to connect to others
22:20 < gmaxwell> phantomcircuit: with it too high you can quite seriously go hours without getting a connection up.
22:20  * BlueMatt ponders the ethicacy of running a crash-pre-0.8.4 script on the network with the goal of getting better stable-node connection
22:20 < phantomcircuit> gmaxwell, sure i remember, i am the one who originally fixed this
22:20 < BlueMatt> or maybe I should just set dnsseed to require 0.8.5
22:20 < gmaxwell> BlueMatt: it would probably partition the network right now.
22:21 < phantomcircuit> i actually was originally asking for a smaller timeout
22:21 < BlueMatt> gmaxwell: yes, thats why you start it slow
22:21 < gmaxwell> (to crash the pre 0.8.4 nodes)
22:21 < phantomcircuit> but i now disagree with myself
22:21 < BlueMatt> so no one else can partition the network by doing it
22:21 < gmaxwell> phantomcircuit: if we had multithreaded connections it would be reasonable to have one running with long timeouts while another ran with short timeouts.
22:22 < phantomcircuit> gmaxwell, we could do that right now actually
22:22 < gmaxwell> I know.
22:22 < phantomcircuit> i'll write a patch to do that after i finish everything else i have to do
22:22 < phantomcircuit> so... never
22:22 < gmaxwell> Right.
22:22  * BlueMatt sets his dnsseed to require 0.8.5
22:22 < BlueMatt> any objections?
22:23 < gmaxwell> I think there are too few nodes.
22:24 < gmaxwell> did you see how many there were? I counted before and there were only a few hundred, you're risking overloading them.
22:24 < BlueMatt> shit
22:24 < gmaxwell> and wrt partitioning the dnsseed stuff mostly controls spv nodes, but since they don't relay they don't help prevent partitioning.
22:24 < BlueMatt> we need auto-update
22:24 < gmaxwell> No we don't.
22:24 < BlueMatt> update-bugging
22:25 < gmaxwell> We made a conscious decision to not use alerts the last several releases. We could use an alert, which we did for 0.8.1
22:25 < BlueMatt> whatever, we need something to tell users "YOURE FUCKED UP HERE, UPDATE"
22:25 < gmaxwell> I'm not really happy with the quality of 0.8.5 (obviously, it's better than 0.8.1...) :(
22:25 < gmaxwell> e.g. software is still basically unusable for many OSX users.
22:26 < BlueMatt> thats largely fixed on 0.9, no?
22:26 < gmaxwell> No.
22:26 < BlueMatt> awww, well I guess I was dreaming :(
22:26 < gmaxwell> There are more fixes than in 0.8.5 but not enough apparently.
22:26 < gmaxwell> If it had been confirmed they worked I'd have backported and we could have done a 0.8.6.
22:26 < gmaxwell> But it sounds like they're not enough.
22:27 < BlueMatt> damn
22:27 < gmaxwell> We also have crash bugs reported on windows that we can't reproduce but seem to be a fair number of people.
22:27 < gmaxwell> And on some debian systems they can't sync the chain due to some signature validation issue.
22:28 < BlueMatt> soo...qa is fucked atm?
22:31 < warren> https://github.com/litecoin-project/litecoin/pull/80 <--- regarding encouraging people to upgrade
22:32 < warren> probably not a good idea, but we're doing it
22:32 < BlueMatt> ewwww
22:32 < BlueMatt> but, yea
22:33 < warren> https://github.com/litecoin-project/bitcoinomg/commits/bitcoin-omg-0.8 <---- here's the bitcoin 0.8 that I personally use
22:34 < warren> it's pretty much litecoin 0.8 without litecoin
22:56 < Luke-Jr> gmaxwell: I probably already have them backported for 0.8.6
22:59 < amiller> http://apps01.mywebapps.net/ajp/bc/g2.png
23:00 < amiller> measured connectivity of the network
23:00 < Luke-Jr> gmaxwell: I could go ahead and do a rc.. quite a few bugfixes.. not sure it's worth it as long as there's outstanding stuff though
23:02 < warren> Luke-Jr: where is your tree?
23:03 < Luke-Jr> warren: the stable tree is on gitorious.org/bitcoin/bitcoind-stable‎
23:03 < Luke-Jr> my personal repo is on gitorious and github separately
23:05 < warren> 404
23:07 < Luke-Jr> odd, I just saw it O.o
23:08 < Luke-Jr> weird
23:08 < Luke-Jr> there's some kind of invisible character on the end of what I pasted here
23:08 < Luke-Jr> gitorious.org/bitcoin/bitcoind-stable
23:13 < BlueMatt> amiller: fun, any theories on what those well-connected nodes or node clusters are?
23:13 < amiller> i think they're bitcoin-roulette
23:13 < amiller> i don't really know though, we're looking into that now
--- Log closed Fri Nov 01 00:00:21 2013