Namecoin Dev IRC Meeting IRC Log - 2014 Jan 2

namecoin-dev-20150201.chat

11:40 -!- mnp_ [~mnp@li244-161.members.linode.com] has joined #namecoin-dev
11:40 -!- Topic for #namecoin-dev: MEETING Jan 3 at 5PM UK time | Namecoin Development | Stable: https://github.com/namecoin/namecoin | http://namecoin.info | https://forum.namecoin.info/ | https://explorer.namecoin.info/
11:40 -!- Topic set by Jeremy_Rand_ [~Jeremy_Ra@ip72-198-31-109.ok.ok.cox.net] [Wed Dec 31 02:05:26 2014]
11:40 [Users #namecoin-dev]
11:40 [@ChanServ    ] [ Blaksmith ] [ fsb4000   ] [ JohnKenney   ] [ mogreen       ] [ wiebel] 
11:40 [@Jeremy_Rand ] [ brand0    ] [ hl        ] [ krzee        ] [ phantomcircuit] [ yrashk] 
11:40 [@Jeremy_Rand_] [ c0rw1n    ] [ indolering] [ Luke-Jr      ] [ setkeh        ] 
11:40 [+ryan-c      ] [ cassiniNMC] [ jbisch    ] [ midnightmagic] [ SudoShell     ] 
11:40 [ _nskelsey_  ] [ deepy     ] [ joesmoe   ] [ mnp_         ] [ tarantillo_   ] 
11:40 -!- Irssi: #namecoin-dev: Total of 27 nicks [3 ops, 0 halfops, 1 voices, 23 normal]
11:40 -!- Channel #namecoin-dev created Thu Jul 28 13:17:12 2011
11:40 -!- Irssi: Join to #namecoin-dev was synced in 0 secs
11:40 -!- You're now known as mnp
11:41 -!- mode/#namecoin-dev [+m] by Jeremy_Rand
11:42 -!- mode/#namecoin-dev [-m] by Jeremy_Rand
11:42 <@Jeremy_Rand> ok, so that appears to work at least
11:42 <+ryan-c> okay
11:50 < mogreen> !time
12:01 <@Jeremy_Rand> Hello everyone
12:01 <@Jeremy_Rand> we'll be starting the meeting shortly
12:02 <@Jeremy_Rand> Okay, so we'll be moderating the channel, and then allowing questions/comments from everyone periodically
12:03 -!- open_moon [458e891b@gateway/web/freenode/ip.69.142.137.27] has joined #namecoin-dev
12:03 <@Jeremy_Rand> I think Luke-Jr requested a ping when the meeting starts, so that has now happened
12:03 < Luke-Jr> ..
12:04 < Luke-Jr> why is the channel being +m'd?
12:04 <@Jeremy_Rand> Luke-Jr: how about we don't do that and we only do it if it becomes too noisy
12:05 < Luke-Jr> +1
12:05 <@Jeremy_Rand> ok, so as long as it's not noisy we'll stay unmoderated
12:05 <+ryan-c> Luke-Jr: I asked Jeremy_Rand to test whether he was able to do it in case it is required (which I do not expect)
12:06 <@Jeremy_Rand> I'm sure some people are curious about Namecore; Daniel informs me that he's unable to be here today, so I guess we'll defer discussion of Namecore until the next meeting
12:06 <@Jeremy_Rand> But I can tell you informally that Namecore is progressing :-)
12:06 <@Jeremy_Rand> So, first topic: lightweight clients.  hl has been working on some documentation of what lightweight client models are possible, can hl talk about that?
12:07 <@Jeremy_Rand> (also, before we get started with that, can everyone who's here for the meeting chime in once so we know you're here?)
12:07 <+ryan-c> (I owe hl some updates to that about models that don't include currency transactions)
12:08 <@Jeremy_Rand> in particular, hl indolering jbisch JohnKenney , are you guys here?
12:08 <+ryan-c> JohnKenney, midnightmagic, cassiniNMC, hl, indolering, jbisch?
12:08 < hl> I'm here.
12:08 < indolering> Hey
12:08 < cassiniNMC> hi
12:08 < jbisch> here
12:08 < mnp> chime
12:09 < indolering> mime
12:09  * indolering is trapped in an invisible box.
12:09 <+ryan-c> indolering: ?_?
12:09 <@Jeremy_Rand> ok, so if hl can fill people in on the lightweight client stuff, that would be most awesome
12:10 < hl> Sure.
12:10 <@Jeremy_Rand> (also, relevant link: https://github.com/hlandau/ncdocs/blob/master/stateofnamecoin.md )
12:10 < indolering> ryan-c: you have something against mimes?  My family has been miming for 6 generations.
12:10 <@Jeremy_Rand> and https://github.com/hlandau/ncdocs/blob/master/nctypes-intro.md
12:10 < indolering> Sprry, go ahead hl
12:10 < indolering> Sorry*
12:11 < hl> OK.
12:13 -!- pmc [~peter@p20030058A572B6A61ACF5EFFFED5F9BE.dip0.t-ipconnect.de] has joined #namecoin-dev
12:13 < hl> There are essentially two lightweight client modes of interest currently currently: UTXO and UTXO with coinbase commitments ("UTXO CB"). The former involves trimming the stored data down to the UTXO set and then optionally applying compression. This still involves storing the current name database, but in many cases this may be small enough to be feasible.
12:14 < hl> A very rough estimate put the order of magnitude of storage used after compression at about 300 MB, which is feasible for use on smartphones.
12:15 < indolering> The name database records are compressible enough to be trivial in size.
12:15 <@Jeremy_Rand> indolering: at current usage levels, correct?
12:15  * indolering did some playing around with record sizes and compression.
12:15 < mogreen> I'm here, chime
12:15 <+ryan-c> hl: was that with or without namespace filtering?
12:15 < indolering> No, it can scale to .info and .biz records.
12:15 < hl> Yeah. Basically, it's thought that the name database will be reasonable in size even with substantial usage levels, the claimed ".info and .biz usage levels".
12:15 < indolering> levels*
12:16 < indolering> Although that depends on us pushing nameservers pretty heavily, but that should be the norm anyway.
12:17 <@Jeremy_Rand> indolering: I'd have to disagree there, nameservers have some disadvantages
12:17 < hl> The 'holy grail' is UTXO CB, though. Essentially this involves computing a cryptographic data structure such as a Merkle tree of the UTXO set and placing the root hash into the coinbase transaction of every block. A phase-in strategy would be used to enforce this; in other words there would be a softfork where miners enforce the correct UTXO attestation value.
12:17 <@Jeremy_Rand> but anyway
12:18 < indolering> Well, it's akin to storing full keys on id/ records.
12:18 <@Jeremy_Rand> My understanding is that Bitcoin is considering something like UTXO CB in the future?
12:18 < hl> I think so, yes.
12:19 <@Jeremy_Rand> Is Luke-Jr able to comment on that?
12:19 < indolering> The only time it makes a lot of sense is for hidden services.
12:19 <+ryan-c> hl: SPV is also possible right now, with the caveat that you'd query multiple servers because one could lie and say a name doesn't exist or give old data.
12:19 <@Jeremy_Rand> indolering: the Google DNS guy I talked to had a use case that would be broken by nameservers
12:19 <+ryan-c> and that works having only the last 36k block headers
12:19 < JohnKenney> hi
12:20 < hl> Essentially, the point of UTXO CB is that it allows proofs of name validity. A lightweight client queries a name via the network and receives the most current name transaction for the desired name; a Merkle branch proving inclusion of that name transaction in a block; the block header for that block; a Merkle branch or similar proving inclusion of the name transaction in the UTXO tree; the coinbase
12:20 < indolering> Jeremy_Rand: forum post?
12:20 < hl> transaction containing the attested tree root, a Merkle branch proving inclusion of that in a block, and the corresponding block header.
12:20 < hl> Note that UTXO CB is an enhancement of SPV36, which is a variant of SPV where only the last 36,000 headers (the name expiry time) are stored.
12:21 <+ryan-c> hl: how does that prevent someone from getting a false negative?
12:21 < hl> A lightweight client would trust the UTXO CB root contained in the block at a threshold depth.
12:22 <@Jeremy_Rand> So, this gets into the idea of a separate Merkle tree for the name database
12:22 <@Jeremy_Rand> Which hl has been informally calling UXNO
12:22 <@Jeremy_Rand> for UneXpired Name Operation
12:22 < hl> ryan-c: It doesn't. Authenticated denial of existence would have to be accomplished separately by using a DNSSEC-style system. For example you could create a second cryptographic tree containing a sorted list of extant names. This tree would be designed such that a Merkle branch proves the existence of two adjacent items in it.
12:23 < hl> So you'd get a Merkle branch for 'There are no names between aaa and bbb, so aab doesn't exist'
12:23 <+ryan-c> okay
12:23 < hl> I call this NX CB, or in conjunction with UTXO CB, UTXO CB+NX CB.
12:23 < hl> This would be a separate root stored in the coinbase.
12:24 < hl> While authenticated denial of existence is desirable, I think it's a lower priority than the affirmative security provided by UTXO CB.
12:24 <@Jeremy_Rand> Are there suggestions on whether that should be called UXNO or something else?  I kind of like UNOP (for Unspent Name OPeration)
12:24 < hl> Ah, right.
12:24 <@Jeremy_Rand> (I realize that names are trivial, but it's good for messaging to have a good name early)
12:25 < hl> So for those unfamiliar with namecoin, it's important to keep in mind a few things. Firstly, name transaction rules are enforced at the network level. As in, an invalid name operation in a block isn't just ignored, but grounds for rejection of the block. Thus presence in a block is a potential sign of validity, depending on depth. This is the foundation of the SPV trust model.
12:25 <@Jeremy_Rand> I dislike using the word "unexpired" because expired means <36k blocks old, while unspent means <36k blocks AND not updated later
12:25 < hl> Now, once a name expires, its coin is marked spent. So for this reason, UTXO and UXNO actually are very similar.
12:26 <@Jeremy_Rand> right, I view unspent as a slightly more restrictive condition than unexpired
12:26 < hl> But since the whole point of UTXO CB is to avoid having to load the whole UTXO tree, I don't see much reason to use coinbase-attested UXNO over the more generally applicable UTXO. That's more likely to harness efforts by Bitcoin to do similar things anyway.
12:27 < jbisch> Jeremy_Rand: Don't you mean expired means >36k blocks old?
12:27 <@Jeremy_Rand> jbisch: you're right, I meant to type "unexpired"
12:27 < hl> Anyway, I think there are a few unresolved issues preventing use of SPV36 or UTXO CB.
12:28 < hl>   +ryan-c | hl: SPV is also possible right now, with the caveat that you'd query multiple servers because one could lie and say a name doesn't exist or give old data.
12:28 < hl> ryan-c: Are you sure about this? The wire protocol doesn't have a get tx by name command, does it?
12:28 <@Jeremy_Rand> hl: yeah, UTXO is higher priority than secure denial of existence
12:28 <@Jeremy_Rand> but we should do both eventually
12:28 <@Jeremy_Rand> (IMO)
12:28 < hl> Yeah.
12:28 < mnp> has anyone thought about something of a merkle tree and skip list hybrid?
12:29 < hl> Elaborate?
12:29 <@Jeremy_Rand> mnp: can you elaborate?
12:29 <+ryan-c> hl: name_history lets you get a tx by name.
12:29 < mnp> ie don't hash everything on the way to cb, but just some subset, say every N on the way
12:29 <+ryan-c> hl: oh, the wire protocol? no.
12:29 < hl> ryan-c: But we're talking SPV, i.e. a headers-only client here...
12:30 < hl> ryan-c: Enabling SPV for namecoin would require a new wire protocol command.
12:30 <+ryan-c> hl: It could be over a separate comms channel
12:31 <@Jeremy_Rand> mnp: can you explain how that is beneficial?
12:31 < mnp> if you look at the vanilla skip list https://upload.wikimedia.org/wikipedia/commons/8/86/Skip_list.svg 
12:32 < mnp> you can traverse every node or if you want a subset, you can just traverse (store?) enough to get there by larger steps
12:32 < hl> Well, first, to state the unsolved problems with UTXO CB. It would be highly desirable and arguably necessary to have some way to efficiently compute changes to the UTXO tree as blocks are processed. I don't think Merkle trees have this property unless you're only appending to the end of the list a Merkle tree represents. And of course whatever data structure is used, it's essential that the ability to
12:32 < hl> generate proofs of inclusion ala Merkle branches is preserved.
12:33 <@Jeremy_Rand> hl: have you looked at the stuff that maaku is working on for Bitcoin?
12:33 < hl> Not sure. I've glanced at the authenticated prefix trees spec, which looks promising.
12:33 < hl> Anyway, there is a second issue.
12:34 < hl> Namely, that in order for this to work, any network node must be capable of generating proofs of inclusion for any UTXO tree a client may want to use as a point of reference, based on its configured SPV trust depth threshold.
12:34 <+ryan-c> the main difference for namecoin is we eventually need authenticated denial of existence of names - bitcoin has no such need, even for transactions.
12:35 < hl> In other words, client A trusts anything 12 blocks old, client B trusts anything 24 blocks old, etc. So nodes have to be able to generate proofs of inclusion for any UTXO tree root in history, which implies they have to keep all of the UTXO trees for every block in history in memory, unless some efficient differential representation is found, which is highly unlikely given the cryptographic properties
12:35 < hl> required.
12:36 < hl> As I've explained, I think authenticated denial of existence and UTXO CB are almost completely orthogonal. They can be implemented separately.
12:36 < hl> The simple solution to this is to support only one or a small number of threshold depths, at the cost of trust flexibility.
12:36 <@Jeremy_Rand> hl: why not standardize on 12?  If an attacker can 51% attack for 12 blocks in a row then they can already steal names, so anything more secure than that is wasteful
12:36 < hl> Right. Standardising on 12 would probably make sense, yes.
12:37 < indolering> So, I think authenticated denial of existence is important but (and correct me if I am wrong here) but an attack exploiting a non-existent name seems low on the feasibility scale.
12:38 < hl> Yeah, pretty much. Though it might be possible if you had some particularly weird name using imports.
12:38 < indolering> i.e. it's okay to wait until we have more engineer resources.
12:38 < hl> Yeah.
12:38 <@Jeremy_Rand> Agreed, it's important long term, but not an immediate concern IMO
12:39 < indolering> engineering*
12:39 < hl> The other issue is privacy. None of this preserves privacy for name requests, since resolution requires other nodes to be queried.
12:40 <@Jeremy_Rand> right, for privacy you can still make optimizations though
12:40 <@Jeremy_Rand> e.g. only receive the last 36k blocks
12:40 < indolering> That is also an orthogonal issue.
12:40 <@Jeremy_Rand> indolering: well, it's a relevant scalabliity optimization
12:40 < indolering> Jeremy_Rand: agreed.
12:41 < hl> If you're going to do that, you may as well just do the trimmed-UTXO mode.
12:41 <@Jeremy_Rand> downloading the last 36k blocks would be a nice optimization that wouldn't take any additional wire commands except getheaders (which is there now as of 0.3.80)
12:41 < indolering> I've got some ideas, but I need to vet them a bit more before suggesting it publicly.
12:41 < indolering> them*
12:42 < hl> Oh, getheaders is in now? That's good, I was worried that was going to break the network once namecore became a thing.
12:42 <+ryan-c> hl: We should standardize on 12 blocks.
12:42 < hl> ryan-c: Yeah.
12:42 <@Jeremy_Rand> hl: getheaders was readded in 0.3.80, I think
12:42 <@Jeremy_Rand> Daniel would know for sure
12:42 <+ryan-c> Jeremy_Rand: "If an attacker can 51% attack for 12 blocks in a row then they can already steal names". < only newly registered ones
12:42 <@Jeremy_Rand> ryan-c: that's correct
12:42 < indolering> FWIW, I think there is funding out there to fix the privacy issue.
12:43 <+ryan-c> but we already have a case where miners able to mine 12 blocks in a row can do nasty things.
12:43 < indolering> Ethereum is interested in funding something.
12:43 <@Jeremy_Rand> indolering: privacy is only an issue if full blocks aren't received
12:43 <+ryan-c> so i think just saying that's our security level is fine.
12:43 < indolering> Yeah.
12:43 < indolering> Full blocks for all names.
12:43 <+ryan-c> if 12 block security level bothers someone, they can run a full node
12:43 <@Jeremy_Rand> and 36k blocks still isn't that much network usage
12:44 < indolering> Jeremy_Rand: agreed, hence the need for more vetting : )
12:44 <@Jeremy_Rand> Is anyone interested in trying to implement a client mode that only downloads the last 36k blocks?
12:45 <@Jeremy_Rand> I guess the first issue there would be having a client that uses getheaders
12:45 < jbisch> You mean like is someone interested in doing the programming?
12:45 <@Jeremy_Rand> jbisch: yes
12:45 < hl> I call that FN36. But is there a point relative to UTXO-trimming mode?
12:45 < jbisch> I guess I might.
12:45 <@Jeremy_Rand> Namecore uses getheaders, does any other client software for Namecore do that?  I don't believe libcoin does
12:45 <@Jeremy_Rand> for Namecoin*
12:45 <+ryan-c> I think the privacy issue is not a huge one - unless the person is going to be hitting a tor node the hostname will probably be sent in the clear by a Host header or SNI anyway.
12:46 -!- pmc [~peter@p20030058A572B6A61ACF5EFFFED5F9BE.dip0.t-ipconnect.de] has quit [Quit: Konversation terminated!]
12:46 <+ryan-c> privacy conscious users can use tor to connect to namecoin as a mitigation
12:46 <@Jeremy_Rand> ryan-c: right, the SPV privacy isn't an issue if you're using Tor
12:46 <@Jeremy_Rand> or rather, it's less of an issue
12:46 < hl> Right. Though Bitcoin has some sort of support for Tor, so we may be able to run UTXO CB queries over onion addresses...
12:46 <@Jeremy_Rand> you need to handle stream isolation properly
12:46 <@Jeremy_Rand> I don't know if Bitcoin does stream isolation in a safe way
12:46 <@Jeremy_Rand> I doubt it
12:47 <+ryan-c> Jeremy_Rand: bitcoin actually supports nodes running on hidden services
12:47 <+ryan-c> Jeremy_Rand: Is stream isolation applicable for long lived connections?
12:48 < jbisch> Can I derail the topic for a bit and ask why this still says 3.8: http://blog.namecoin.org/post/105749327770/new-version-3-8-softfork ?
12:48 <@Jeremy_Rand> ryan-c: if the same TCP connection is used to access 2 different .bit domains via the Namecoin wire protocol, that leaks private data
12:48 <+ryan-c> Jeremy_Rand: what?
12:49 <+ryan-c> indolering: should be 0.3.80, please fix
12:49 <@Jeremy_Rand> ryan-c: ideally you want to establish separate hidden service connections for different identities
12:49 <@Jeremy_Rand> otherwise the hidden service operator can tell that two requests were the same user
12:49 <+ryan-c> Jeremy_Rand: You mean querying the same node for multiple different .bit domains?
12:49  * indolering is changing it now.
12:49 <+ryan-c> Jeremy_Rand: I do not think this is a problem bitcoin has
12:50 <@Jeremy_Rand> ryan-c: querying the same set of nodes for .bit domains (especially if it's the same TCP connection) that are part of different TorBrowser identities, is a Bad Thing (TM)
12:50 <@Jeremy_Rand> It's an issue for Bitcoin too
12:50 <@Jeremy_Rand> because it links ownership of coins
12:51 <@Jeremy_Rand> but I'm guessing they haven't dealt with that
12:51 <@Jeremy_Rand> seeing as there are easier ways to link coins
12:51 <+ryan-c> Jeremy_Rand: I think that would require frequently rotating what nodes one is connected to.
12:51 <+ryan-c> Jeremy_Rand: which would fall over real quick for high rate of lookups
12:52 <@Jeremy_Rand> ryan-c: yep, Tor changes the entire circuit for each identity
12:52 <@Jeremy_Rand> ryan-c: no, it wouldn't be per domain
12:52 <@Jeremy_Rand> it would be per identity
12:52 <@Jeremy_Rand> as per the SOCKS proxy username/password that Tor receives
12:52 <+ryan-c> Jeremy_Rand: but then namecoin would need a concept of identity
12:53 <@Jeremy_Rand> ryan-c: you can get that from TorBrowser if you have a proxy between TorBrowser and Tor
12:53 <@Jeremy_Rand> which you probably need anyway if you're doing .bit to .onion
12:53 <@Jeremy_Rand> basically Namecoin would have an argument for name_show
12:54 <+ryan-c> Jeremy_Rand: but namecoin doesn't support identities
12:54 <@Jeremy_Rand> which would be an indentity
12:54 <+ryan-c> yes, it would need an argument to name_show
12:54 <@Jeremy_Rand> and Namecoin would maintain separate peer connections per identity
12:54 <+ryan-c> probably something to implement "in the future"
12:54 <@Jeremy_Rand> right, it's important if we care about browsing anonymity
12:54 <@Jeremy_Rand> which we will at some point
12:55 <@Jeremy_Rand> but it's not a huge priority since right now we don't even work with TorBrowser at all
12:55 < hl> This seems pretty niche to me. Most of the time, it doesn't matter if someone can say "there exists a person who visited both a.bit and b.bit, but I have no idea who"
12:55 < hl> So it would be nice to solve, but shouldn't be a priority.
12:55 <@Jeremy_Rand> hl: turns out that it's attackable pretty often, the Tor guys spent a lot of effort fixing that
12:55 <@Jeremy_Rand> depends on your threat model obviously
12:55 < hl> Hmm.
12:55 <@Jeremy_Rand> for Tor's threat model it matters
12:56 <@Jeremy_Rand> Let's say that ilovehellokitty.bit is only visited by 2-3 people
12:56 <@Jeremy_Rand> and wikileaks.bit is visited by a lot of people
12:56 <@Jeremy_Rand> you don't want to leak the fact that one of those 2-3 people sent a large document to wikileaks.bit
12:57 < mnp> right, they call that traffic analysis. timing is also considered
12:57 <@Jeremy_Rand> yep
12:57 < hl> But how could that happen? It's just 'There is only one person who visits both sites, and he's visiting wikileaks right now.'
12:57 <@Jeremy_Rand> hl: you can correlate with external info
12:58 <@Jeremy_Rand> and keep in mind that one of the websites might be evil too
12:58 < hl> Hmm....
12:58 <@Jeremy_Rand> let's say wikileaks.bit is a scam site entrapping whistleblowers
12:58 <@Jeremy_Rand> and they also are controlled by the same guy who sees you contact both wikileaks.bit and ilovehellokitty.bit
12:59 <@Jeremy_Rand> now they have a lot of evidence for exactly who connected to wikileaks.bit, combined with what was uploaded to it
12:59 <+ryan-c> Jeremy_Rand: or they just drop an 0day on the visitors who upload things
12:59 < hl> And the resolver circuit and the wikileaks circuit can be correlated?
12:59 < mnp> you have to assume isp data is in the clear
12:59 <@Jeremy_Rand> yes, if nothing else based on timing
13:00 < hl> Hmm, yes.
13:00 <@Jeremy_Rand> This seems like something that would be nice to get merged into Bitcoin if we do fix it
13:01 <@Jeremy_Rand> because linking coins sucks
13:02 <@Jeremy_Rand> ok, so
13:02 <@Jeremy_Rand> what are the barrier to implementing a 36k FN client?
13:02 <@Jeremy_Rand> What existing Namecoin client implementations can handle getheaders at the moment?
13:03 <@Jeremy_Rand> Namecore is one
13:03 <@Jeremy_Rand> (by handle, I mean sync using)
13:03 <@Jeremy_Rand> hl: did you do something with btcd?
13:04 < hl> I have a rough port of btcd to namecoin, yes. It uses getheaders, so it fell over when I pointed it at namecoind (this was before 0.3.80). It syncs when pointe at namecore thoug.
13:05 <@Jeremy_Rand> I might be able to rig libcoin to only store 36k of names.  I've glanced at the code, it doesn't look too bad.  But libcoin doesn't sync with getheaders, so it would have to download the full chain
13:06 <@Jeremy_Rand> but, I don't have an ETA on when I might be able to do that with libcoin
13:06 <@Jeremy_Rand> hl: how suitable is the btcd codebase for a 36k FN client?
13:06 <@Jeremy_Rand> (preferably pruning non-name transactions)
13:08 < jbisch> indolering: You are so close with the blog post title. Just add a 0. in front of the 3.80.
13:08 < hl> Hmm. 36k FN seems like it wouldn't be hard to apply to any full node, since it's not in principle a complex change, just throwing away data that's not going to be asked for. Though I've found that btcd is razor-focused on precisely implementing a Bitcoin full node, so it's probably a lot less adaptable than libcoin.
13:08 < indolering> jbisch: derp
13:09 <@Jeremy_Rand> hl: ok.  So maybe I'll play around with libcoin, and you can play around with btcd, and we'll see which one works better?
13:09 < hl> Sure.
13:09 <@Jeremy_Rand> sounds like a plan
13:09 <@Jeremy_Rand> (my libcoin install is on an old computer, so I won't be able to do that in the next few days until I get that transferred)
13:10 <@Jeremy_Rand> ok, so
13:10 <@Jeremy_Rand> next order of business: NMControl
13:10 <@Jeremy_Rand> It would be excellent to have an RPC call that returns a DNS-formatted record for a given .bit domain and request type; this would help with Unbound integration
13:11 <@Jeremy_Rand> Anyone here who likes DNS and Python who'd like to implement that?
13:12 <@Jeremy_Rand> heh, no takers?  :-)
13:12 < mnp> in namecore?
13:12 <@Jeremy_Rand> mnp: in NMControl, it's the .bit parser, written in Python
13:12 <@Jeremy_Rand> Namecore only deals with the name/value system generally; everything .bit related is in NMControl
13:13 <@Jeremy_Rand> indolering: were you talking to sdgathman about doing that at some point?
13:13 < indolering> He was interested in porting over unit tests.
13:14 < indolering> I wouldn't mind taking a stab at it, but I have very little experience with both Python an DNS.
13:14 <@Jeremy_Rand> ok... if you can find someone who's willing to check your work and who knows DNS well, then it's totally fine for you to do it
13:15 <@Jeremy_Rand> I prefer not to do it myself, as my low-level DNS skills are kind of sketchy
13:15 < indolering> Jeremy_Rand: Yeah, that would be you, hl, and sdgathman :P
13:15 < jbisch> I know Python, but probably not DNS enough.
13:15 <@Jeremy_Rand> hl: would you be up for checking indolering's work if he implements it?
13:16 <@Jeremy_Rand> or we could ask sdgathman, but he's not here rihgt now
13:16 < hl> Perhaps. Though I'm not sure that much is accomplished by moving from DNS as the interface between Unbound and NMControl and Python based on RPC.
13:17 <@Jeremy_Rand> hl: well, the RPC call would incorporate logic that's useful in dealing with Unbound.  Whether the RPC interface itself is used with Unbound is a different (and open) question
13:17 < indolering> We wanted to convert NMControl to python 3, should we do that first?
13:18 < indolering> And do we have proper unit testing on NMControl?
13:18 <+ryan-c> Jeremy_Rand: I can check his work.
13:18 <@Jeremy_Rand> indolering: I would love to do Python 3, I think phelix wasn't happy about it, for reasons that didn't make much sense to me
13:18 <+ryan-c> I know DNS pretty well.
13:18 <@Jeremy_Rand> but I'm totally fine with Python 3
13:18 < hl> Well, I think stub-zone is the simplest solution, really. Since then Unbound does all the classification of records into the right response sections, etc. Whereas the Python API in Unbound seems quite low level, though I'll have to verify that.
13:18 <@Jeremy_Rand> it would be a big endeavor though
13:19 < indolering> Waiting only makes it bigger.
13:19 <+ryan-c> Jeremy_Rand: There are still a lot of modules that don't work in python 3
13:19 < indolering> It is technical debt, loads of it.
13:19 < indolering> ryan-c: Any that are important to NMControl?
13:19 <@Jeremy_Rand> hl: well, the issue is that I want to get rid of PyDNS and PyMDS, and the easiest way to do that is to use the Unbound Python interfaces
13:19 <@Jeremy_Rand> PyDNS and PyMDS don't support DNSSEC and haven't been subject to nearly any auditing
13:20 <+ryan-c> unbound is a good idea
13:20 < hl> Are you using PyDNS/PyMDS just for wire protocol encoding, or for logic on top of that?
13:21 <@Jeremy_Rand> hl: the DNS server in NMControl is a hacked version of PyMDS by some random guy on BitcoinTalk, and PyDNS is used for looking up stuff from other nameservers... I don't recall exactly how they're used
13:21 <@Jeremy_Rand> but I really want to scrap everything that uses them
13:22 < hl> Ah. I can see that, yeah.
13:22 < hl> Especially if it's acting as a recursive resolver.
13:22 <@Jeremy_Rand> yeah
13:22 <@Jeremy_Rand> it's a mess
13:22 < indolering> Also, I would prefer to implement a more modular system of translation based on transports.
13:23 < hl> What you could do, then, is just write a minimal wire protocol library and use that to send records to Unbound via stub-zone. Unbound then does all the recursive resolution, so NMControl would be obligated to implement an authoritative nameserver for .bit only.
13:23 < indolering> If I understand the task correctly, I'm basically writing a d/ record -> DNS record converter.
13:23 <@Jeremy_Rand> hl: I really don't like writing libraries that we have to maintain ourselves, however minimal they are
13:24 < hl> I think the in-process Python solution is risky, because failures could take out Unbound as a whole, which won't break just .bit.
13:24 <@Jeremy_Rand> hl: are you sure?  What kind of failures would be plausible?
13:24 < indolering> But we also have to handle Tor, i2p, http, etc, etc.
13:24 < hl> Jeremy_Rand: Not sure? I guess if you stick to safe Python and handle exceptions it should be fine.
13:25 < hl> It also forces rather tight couping and the use of Unbound.
13:25 <@Jeremy_Rand> If nothing else we could use the RPC interface from Unbound's Python interface... although that seems a bit drastic... I'd suggest testing a bit to see how stable Unbound's Python interface is
13:25 <@Jeremy_Rand> Well, right now we're forcing use of PyDNS and PyMDS
13:26 <@Jeremy_Rand> I'd rather force Unbound than that
13:26 <@Jeremy_Rand> and I'd rather force Unbound than some other library that we wrote ourselves
13:26  * Jeremy_Rand has bad experience with building stuff himself
13:26 < hl> True enough.
13:27 <+ryan-c> parsing dns ourselves is a terrible idea
13:27 <+ryan-c> emitting dns records is a kinda bad idea
13:27 <+ryan-c> er
13:27 <+ryan-c> implementing our own thing to generate dns wire data
13:28 <@Jeremy_Rand> yeah, I've seen too many failures to properly implement edge cases even in simple protocols
13:28 <+ryan-c> Jeremy_Rand: did you know that dns has some very limited built in support for compression?
13:29 <@Jeremy_Rand> ryan-c: that sounds like it could end badly
13:29 -!- deepy [deepy@acehack.de] has quit [Quit: ZNC - http://znc.in]
13:29 <@Jeremy_Rand> ok, so indolering can play around with converting d/ to DNS in an RPC call; ryan-c can check his work?
13:30 <+ryan-c> that is the plan
13:30 <@Jeremy_Rand> ok.  So, related task: format validation
13:30 <@Jeremy_Rand> NMControl will spit out whatever text is in an "ip" record for example
13:30 <+ryan-c> Jeremy_Rand: (not really relevent, but...) http://www.tcpipguide.com/free/t_DNSNameNotationandMessageCompressionTechnique.htm (note that it's three pages)
13:30 <@Jeremy_Rand> even if it's not an IP address
13:30 <@Jeremy_Rand> this needs to be fixed
13:31 <@Jeremy_Rand> basically all of the RPC calls should not output data that's clearly malformed
13:31 <+ryan-c> that is a good idea
13:31 <@Jeremy_Rand> like the idiot who's shoving Bitmessage addresses into a "translate" field
13:32 <@Jeremy_Rand> Do we have any volunteers who would like to implement such validation?
13:32 -!- Guest58546 [znc@acehack.de] has joined #namecoin-dev
13:33 < indolering> Jeremy_Rand: I'm pretty sure that would fall to me.
13:33 <@Jeremy_Rand> indolering: go for it :-)
13:33 <+ryan-c> i will help indo regular expression
13:33 <@Jeremy_Rand> yay
13:33 < indolering> I've already spent a lot of time on this task, both research wise and implementing checks for Speech.is.
13:33 <@Jeremy_Rand> cool
13:34 <@Jeremy_Rand> ok, next up -- jbisch has been porting NMControl to Android... jbisch can you tell us about how that's going?
13:35 < indolering> I would prefer using a PEG.
13:35 < indolering> Whoa, can we cover Python 2 to 3 first?
13:36 <@Jeremy_Rand> um, sure, I guess
13:36 <@Jeremy_Rand> I'm fine with Python 3... phelix isn't here and he had some objections to it
13:37 <@Jeremy_Rand> if someone wants to run NMControl through a converter and see how much stuff needs manual changing, that would be interesting
13:37 < indolering> I would prefer to do the port before adding a lot of functionality but as someone with minimal Python experience I don't think I'm the right person for the job. Does anyone here have experience with porting to Python 3?
13:37 < jbisch> Me
13:38 < jbisch> Most of the stuff is usually not too hard.
13:38 < indolering> Jeremy_Rand: I tried that but I had trouble with 2to3's reporting.
13:38 <@Jeremy_Rand> jbisch: cool, let's talk to phelix and see what his concerns are... if you're able to do it and phelix is cool with it then that would be most welcome
13:38 < indolering> jbisch: want to work together on that?
13:38 < jbisch> indolering: Sure.
13:38 <@Jeremy_Rand> ok great
13:38 <@Jeremy_Rand> anything else before we move on to Android?
13:38 < indolering> I have an idea of what needs to be replaced, if you can handle checking the 2to3 output.
13:39 < indolering> No, go ahead.
13:39 <@Jeremy_Rand> ok, so can jbisch tell us about how the Android port is going?
13:39 < jbisch> First the link to the code: https://github.com/josephbisch/nmcontrolandroid
13:40 < jbisch> It's going good. I can run nmcontrol on the android device and access the rpc and dns from another computer on the same network.
13:40 < jbisch> Can't do anything practical with just the android device until a proxy is implemented into nmcontrol.
13:41 <@Jeremy_Rand> jbisch: can you access the NMControl DNS from Android?
13:41 <@Jeremy_Rand> (I realize that would probably require root)
13:41 < jbisch> Not unless you are rooted, because you need to run on port 53.
13:41 <+ryan-c> could run on 5353
13:42 <@Jeremy_Rand> I mean, lots of people root their Android phones, is that a big dealbreaker?
13:42 < jbisch> But if you are rooted, you can change the port to 53. Then you also need to programmatically change the dns, which nmcontrol for android doesn't do yet.
13:42 < jbisch> Android doesn't let you set the dns with a port afaik.
13:42 <+ryan-c> do we need dns for android?
13:43 <+ryan-c> as a service?
13:43 <@Jeremy_Rand> jbisch: there's an app in F-Droid which can change DNS settings, even on 3G, I don't think it lets you control the port though
13:43 <+ryan-c> we could just provide a proxy
13:43 <@Jeremy_Rand> ryan-c: right, that gets to my interest in mitmproxy
13:44 <@Jeremy_Rand> which is actually on my list of things to bring up, but a bit further down
13:44 -!- Guest58546 [znc@acehack.de] has quit [Quit: ZNC - http://znc.in]
13:44 < jbisch> By the way, if anyone is interested in the line they need to change to get dns on port 53: https://github.com/josephbisch/nmcontrolandroid/blob/master/src/info/namecoin/nmcontrolandroid/ScriptService.java#L181
13:44 <+ryan-c> providing a proxy means not needing root (i think)
13:45 <@Jeremy_Rand> ryan-c: that's correct, although you need to configure apps to use the proxy
13:45 <@Jeremy_Rand> Orbot benefits from root because then it can use a transparent proxy
13:45 < jbisch> Yes, you don't need root if you have a proxy. You can, for example, use Firefox.
13:46 <@Jeremy_Rand> ok, so since that has come up, let's discuss that now
13:46 <@Jeremy_Rand> right now the proxy implementation we're using on PC's is Convergence
13:46 <@Jeremy_Rand> it's kind of nice in that it can do TLS validation
13:46 <@Jeremy_Rand> but it's Javascript
13:47 <@Jeremy_Rand> and isn't really maintained at this point
13:47 -!- deepa [deepy@acehack.de] has joined #namecoin-dev
13:47 <@Jeremy_Rand> the Convergence maintainer (Mike) basically told me it was better for us to use a Python SOCKS proxy that terminates TLS, rather than keep hacking on Convergence
13:47 <@Jeremy_Rand> mitmproxy is exactly that
13:47 <@Jeremy_Rand> it's actively maintained
13:48 <@Jeremy_Rand> and the mitmproxy devs seem quite willing to assist us in whatever we need
13:48 <@Jeremy_Rand> I would support using mitmproxy, I think indolering said he agrees
13:49 <@Jeremy_Rand> Ryan expressed some concerns about it -- Ryan would you like to comment on that now?
13:50 <+ryan-c> Jeremy_Rand: My concern is that the design goals of mitmproxy did not include being secure against active or even passive upstream man-in-the-middle.
13:51 <+ryan-c> Jeremy_Rand: It currently doesn't do validation of certificates nor does it use best practices as far as cipher suites are concerned.
13:51 <+ryan-c> I haven't dug around much in the code to see if there's anything else to be concerned about
13:51 <@Jeremy_Rand> ryan-c: ok, so I talked to Max (mitmproxy dev)... validation of certs would be done by us anyway (and Max is willing to help us add hooks for that); the cipher suites are configurable by command line as far as I can tell
13:51 <+ryan-c> but those problems shoudln't be that hard to fix
13:51 <@Jeremy_Rand> Max doesn't think it will be hard to make it suitable for us
13:52 -!- jonasbits [~quassel@78-73-105-79-no162.tbcn.telia.com] has joined #namecoin-dev
13:52 <+ryan-c> we also probably should add the ability to only intercept ssl for specific TLDs
13:52 <@Jeremy_Rand> ryan-c: is there another proxy solution that is closer to what we would want with regards to TLS termination and other .bit features?
13:52 <+ryan-c> there's also the no client certs when intercepting thing, but hardly anything uses client certs
13:53 <+ryan-c> Jeremy_Rand: Not that I'm aware of.
13:53 <@Jeremy_Rand> ryan-c: and yes, we should only terminate TLS for .bit
13:53 <@Jeremy_Rand> ok, so is it okay in your opinion to use mitmproxy on the condition that we get the relevant features added?
13:54 <+ryan-c> Jeremy_Rand: we should also look at SSLBump.
13:54 <+ryan-c> (part of squid)
13:54 <+ryan-c> it has some nice things like 'error condition mirroring'
13:55 <+ryan-c> in general it will generate certificates that better match the presented ones
13:55 <@Jeremy_Rand> ryan-c: I believe I looked at that recently and decided that mitmproxy was closer to what I was looking for, but I don't recall the details
13:55 <@Jeremy_Rand> I Googled for it and the URL was already in my recent history
13:55 <@Jeremy_Rand> so I know I looked at it recently
13:55 <+ryan-c> Jeremy_Rand: well, we can always just lift algorithms from it.
13:55 <+ryan-c> Jeremy_Rand: x509 is a bitch to get right
13:56 <@Jeremy_Rand> yeah, I'm totally fine with borrowing algos from Squid
13:56 <@Jeremy_Rand> so is mitmproxy approved then?
13:56 <+ryan-c> i suppose
13:57 <@Jeremy_Rand> yay
13:57 <@Jeremy_Rand> anything else about the proxy stuff before we move on to Armory?
13:58 <@Jeremy_Rand> ok, I guess we're moving on to Armory
13:58 <@Jeremy_Rand> jbisch has been porting Armory to Namecoin
13:58 <@Jeremy_Rand> jbisch: do you want to tell us how that's going?
13:59 < jbisch> I am on my phone now, so I won't link.
13:59 <@Jeremy_Rand> ok
14:00 < jbisch> I have basic support, which is sending and receiving namecoins but not namrs.
14:00 < jbisch> idk any questions?
14:00 <@Jeremy_Rand> Do I understand correctly that Alan is willing to merge in the future, but not now?
14:01 < jbisch> yes, they are just too busy with funding and enterprise customer features, but yes in the future.
14:01 <@Jeremy_Rand> What's needed before we can get a public release out there for Namecoin currency users to play with?  Anything in particular need beta testing?
14:02 < jbisch> Just the tests need to be working and we need more people testing with testnet namecoins. Just me and one person tested.
14:03  * indolering needs to work on the UI.
14:03 <@Jeremy_Rand> ok
14:03 <@Jeremy_Rand> does anyone here volunteer to test with some testnet namecoins?
14:03 < jonasbits> I think im the extra person :-)
14:03 < jbisch> yes you are
14:03 < mnp> i can play with it also
14:03 <@Jeremy_Rand> excellent
14:04 <@Jeremy_Rand> indolering: I've got a partially written UI for name JSON generation in Armory, but it's blocked by some missing NMControl features
14:05 <@Jeremy_Rand> once NMControl has the necessary features I would love some feedback on my UI
14:05 < indolering> Jeremy_Rand: okay.
14:05 <@Jeremy_Rand> ok, anything else with Armory?
14:05 < indolering> Honestly, client side generation is an advanced feature and a "bad" UI can help filter people who shouldn't be doing it themselves.
14:06 < jbisch> I don't think so.
14:06 < indolering> bad = requires understanding of implementation
14:06 <@Jeremy_Rand> ok, so
14:06 < indolering> That being said, it should still be as good as possible.
14:06 <@Jeremy_Rand> next topic: namecoin.info and HTTPS
14:06 < indolering> It's just a lower priority for me.
14:06 < indolering> Yay!
14:07 <@Jeremy_Rand> ryan-c: what's the status on this?  last I heard we needed automatic Git pulls set up on the new server
14:07 <@Jeremy_Rand> is there something more than that that I don't know about?
14:07 < indolering> ryan-c: that's your cue.
14:07 <+ryan-c> Jeremy_Rand: Yeah, I should have done that by now but haven't.
14:07 <+ryan-c> Jeremy_Rand: No, I've just been busy. :-/
14:07  * Jeremy_Rand feels like we keep giving ryan-c new tasks when he's the only one who can safely deal with those certs
14:08 <+ryan-c> mostly holidays and wedding planning, work has lightened up.
14:09 <@Jeremy_Rand> ryan-c: would you be okay with not working on other Namecoin stuff until the HTTPS and new server are set up?  I feel like we tend to give you new stuff to do, which is actually lower priority than the website at the moment
14:09 <+ryan-c> also some other personal stuff that is now sorted.
14:09 <@Jeremy_Rand> (I don't mean that in a mean way :-) )
14:09 <+ryan-c> Jeremy_Rand: That's fine. I've been having some problems lately not taking on more stuff than I can actually do.
14:10 <+ryan-c> no offense taken
14:10 <@Jeremy_Rand> ok
14:10 <@Jeremy_Rand> :-)
14:10 <@Jeremy_Rand> anything else about the website before we move on to a new topic?
14:10 <+ryan-c> no, i think i have everything needed
14:10 <@Jeremy_Rand> ok
14:11 <@Jeremy_Rand> so next topic: funding
14:11 <@Jeremy_Rand> I have several hundred USD which is earmarked for Namecoin bounties, but must be committed to specific tickets before mid-March
14:11 <@Jeremy_Rand> suggestions on things I should sponsor?
14:12 < indolering> Jeremy_Rand: what are the restrictions on spending?
14:12 <+ryan-c> Jeremy_Rand: ATM, we should focus on getting the code to a more maintainable state, which means namecore or libcoin based stuff.
14:13 < indolering> I suggested we use it to pay for namecoin.org or TLS certs but you mentioned some restrictions....
14:13 <+ryan-c> Jeremy_Rand: we could break those down into smaller tasks.
14:13 < mnp> anybody want to comment on namecore vs libcoin as a prio moving forward?
14:13 <@Jeremy_Rand> indolering: for most of it, anything related to development of Namecoin projects, but it cannot go toward my dev work... there's a small part of it which is marked "miscellaneous" which could go toward server costs, I'm not sure offhand what that number is
14:15 <+ryan-c> mnp: domob has been working on that and he isn't here right now, not sure how familiar anyone else is.
14:15 < jonasbits> I would like to see a Testnet Block Explorer
14:15 <@Jeremy_Rand> mnp: I think Namecore is going to be the "reference implementation", but libcoin will still play a role as long as it's useful... domob would be better equipped to answer though
14:15 < indolering> We could ask Namecha.in to do that.
14:15 <+ryan-c> jonasbits: I would suggest we ask namecha.in to add one.
14:15 < indolering> We also need them to start tracking miner ratios.
14:16 <@Jeremy_Rand> libcoin is much easier to adapt for e.g. pruned databases
14:16 < indolering> And IP addresses of mined blocks.
14:16 <@Jeremy_Rand> so for lite client stuff libcoin is really nice
14:16 < jonasbits> That would be great if they could be convinced
14:16 <+ryan-c> jonasbits: I have access to the old explorers that khal wrote, but the code is pretty messy.
14:16 <@Jeremy_Rand> I would like to have an open source block explorer
14:16 <@Jeremy_Rand> that handles names
14:16 < indolering> Jeremy_Rand: would that fall under "misc" or development?
14:16 <@Jeremy_Rand> I could put a bounty on that if it would be helpful.
14:16 <+ryan-c> Jeremy_Rand: ask khal if i can open source his, i have the code.
14:16 <@Jeremy_Rand> That would be development
14:17 <+ryan-c> Jeremy_Rand: also ask namecha.in
14:17 <+ryan-c> Jeremy_Rand: we could also adapt insight pretty easy
14:17 < jonasbits> ryan-c: insight would be great if it could be done
14:18 <@Jeremy_Rand> ok
14:18 <+ryan-c> indolering: If anyone wants to set up a website tracking miner ratios I'll share my code with them.
14:18 <+ryan-c> it emits json
14:18 <@Jeremy_Rand> I'm not sure I want to bother khal again, I felt really weird contacting him at work
14:18 <+ryan-c> so really  all it needs is visualication
14:18 < cassiniNMC> namecoin.webbtc.com used to have a testnet explorer IIRC,
14:18 < cassiniNMC> it is frozen ATM, though
14:19 <@Jeremy_Rand> But I guess if I'm offering him money for code that he doesn't use anymore, he might not mind if I contact him at work again
14:19 < jonasbits> cassiniNMC: yea i remember that, but could not find it when i needed to use one
14:19 < indolering> I'll send an email to Namecha.in asking for quotes to expose miner information, track IP's of first to report a mined block, and open sourcing the backend.  Anything else?
14:19 <+ryan-c> insight shouldn't be difficult fwiw, you'd just have to add search by name (can use the name_history api for namecoind if you have to) and parsing of name transactions (which isn't hard)
14:20 <+ryan-c> indolering: Tell them I have patchs for looking at merged mining info for pool attribution that i can give them
14:20 < indolering> ryan-c: If my memory serves me correctly, you still have a rather large "unknown" percentage.
14:21 <+ryan-c> indolering: we do not
14:21 < indolering> Okay.
14:21 <+ryan-c> indolering: it was 1-2% unknown
14:21 < indolering> ryan-c: great!
14:21 <+ryan-c> indolering: I can identify all the pools blockchain.info does
14:22 < indolering> ryan-c: okay.
14:22 <@Jeremy_Rand> anything else about funding that we should talk about?
14:22 <+ryan-c> what happened with discus fish?
14:23 < indolering> ryan-c: we get 20KNMC
14:23 <@Jeremy_Rand> ryan-c: not sure, Daniel would be the person to ask about that
14:23 <+ryan-c> okay
14:23 < indolering> Not sure about the bonus
14:23 < indolering> Shuttleworth turned us down, but I messed up when I initially applied and had to redo everything in 24/hours.
14:23 < indolering> And DNSChain fucking applied as well so they were confused.
14:24 < indolering> So I am going to reapply.
14:24 < indolering> I've got grant requests out for NLNet and the OpenTechFund.
14:24 <@Jeremy_Rand> hopefully Daniel will be at these meetings usually going forward, he said he had some conflicts in early January but he's free at this timeslot going forward from there
14:24 < indolering> Should be hearing from them soon.
14:24 <+ryan-c> okay
14:24 <+ryan-c> next?
14:24 < indolering> I'm flying to Virginia tomorrow to meet with the BitShares team.
14:24 < indolering> They might have funding.
14:24 < indolering> But that's still very preliminary.
14:24 < indolering> But yeah, next.
14:24 <+ryan-c> didn't they already go back on a funding promise already?
14:25 <+ryan-c> doesn't matter
14:25 <@Jeremy_Rand> so that's the last thing from my list of stuff... so now I guess we go down the list of devs who might have something else to bring up -- cassiniNMC , anything you'd like to talk about?
14:25 < indolering> ryan-c: yeah, it's complicated.
14:25 < indolering> They are paying me to fly out so ....
14:26 < cassiniNMC> 0.3.80 for mac...
14:26 <@Jeremy_Rand> ok yeah, so what's going on with that?
14:26 < cassiniNMC> i need to get in touch with jedimstr, who
14:26 < cassiniNMC> is the one with a non-SSE4 mac
14:27 <@Jeremy_Rand> ok
14:27 < cassiniNMC> Haven't heard anything from his tests during the last days,
14:27 <@Jeremy_Rand> anything else?
14:27 < cassiniNMC> however, today I pinged his client with a version and a getheaders message,
14:27 < jonasbits> my mac is from 2006 if that is any help
14:28 < cassiniNMC> and it replied with version = 38000 and a nicely formatted headers reply.
14:28 < cassiniNMC> jonasbits: can it do Yosemite?
14:29 < jonasbits> cassiniNMC: no im stuck at Leon
14:29 < cassiniNMC> In this case it doesn't help us
14:30 < cassiniNMC> While we have indo around ... indolering:  have you had a look at the betabuild I sent you a while ago?
14:30 <@Jeremy_Rand> There are some Yosemite machines in the OU CS lab, the IT guy has previously let me test Namecoin stuff on it... I'm not sure about SSE4, but it's a university lab, so probably they're pretty old
14:30 < indolering> Not in depth.
14:31 < indolering> I think it runs but I've been stuck on a corrupted wallet issue.
14:31 <@Jeremy_Rand> cassiniNMC: should I check on whether any of those machines is suitable for testing stuff for you?
14:31 <+ryan-c> indolering: i still need someone to test my wallet recovery tools, sugarpuff is a flake
14:32 <+ryan-c> indolering: if you wanna send me a wallet.dat i can try it myself
14:32 < indolering> ryan-c: I can do that.
14:32 < cassiniNMC> Jeremy_Rand: excellent, old CPUs with 10.9 Mavericks or 10.10 Yosemite is what we need for this test,
14:33 < indolering> I have a backup, but neither the beta nor the previous QT build will open it.
14:33 < indolering> They just crash on startup when I restore the .namecoin directory : (
14:33 <@Jeremy_Rand> cassiniNMC: ok cool, next time I'm in the CS lab (roughly 1.5 weeks from now) I'll check on it (if I remember)
14:34 <@Jeremy_Rand> anything else cassiniNMC ?
14:34 < cassiniNMC> indolering:  did it start at all?
14:34 < indolering> Splash screen then shut down.
14:36 < cassiniNMC> as soon as we do the release 0.3.80 for Mac
14:36 < cassiniNMC> I'm updating the wiki on How to Build Your Own Namecoin-Qt,
14:36 < indolering> cassiniNMC: please
14:37 < indolering> cassiniNMC: do you have privileges on the forum?
14:37 < cassiniNMC> and if technically feasible I'll try to write an "easymacbuilder".
14:37 < cassiniNMC> which privileges?
14:37 <@Jeremy_Rand> cassiniNMC: with Namecore we will probably be using Gitian (so cross-compile everything from Linux)
14:37 < indolering> Err, the wiki.
14:38 < indolering> cassiniNMC: if you need any, just ask.
14:38 < indolering> I think I made you an editor.
14:38 < cassiniNMC> yes, I can write in the wiki.
14:38 < indolering> Jeremy_Rand: yeah, we need to figure out an automated build system for Namecore.
14:38 < indolering> And everything else.
14:39 < cassiniNMC> ah, Gitian, I have to have a look into it.
14:39 <@Jeremy_Rand> indolering: I expect the Gitian scripts from Bitcoin Core to work almost verbatim for Namecore
14:39 < indolering> Or, rather, we need to figure out an automated build system and introduce it once we switch Namecore to the mainline branch.
14:39 <@Jeremy_Rand> if they don't, then that would mean Daniel broke something
14:39 <@Jeremy_Rand> right, I was talking to Daniel about automated builds
14:40 <@Jeremy_Rand> I'm going to try both Travis CI and Drone.io
14:40 <@Jeremy_Rand> Drone.io is probably adaptable to work with Gitian
14:40 <@Jeremy_Rand> it uses Docker
14:40 < mnp> travis is pretty nice
14:40 <@Jeremy_Rand> and it's open source
14:40 < indolering> Jeremy_Rand: I would suggest you, jbisch, or PMC work on setting a workflow for automated builds of Namecore.
14:40 <+ryan-c> how much more did we want to cover? we're coming up on three hours.
14:40 <@Jeremy_Rand> yeah, we've been here a while
14:41 <@Jeremy_Rand> hl: anything else you want to cover?
14:41 <+ryan-c> I did want to hear what the other people here thought about making CA certificates for .bit happen so that I can respond to my contact next week.
14:42 <+ryan-c> tl;dr: I have a contact at a CA that is interested in issuing certificates for .bit. I would like to work with them to define policy, specifically, make sure that a valid TLSA record is *required* to get a cert. This makes several adoption methods easier and doesn't decrease security (though it may *appear* to increase security more than it *actually* does in some cases). So far domob and indo were in favor, and jeremy was against.
14:42 <@Jeremy_Rand> Yeah, I generally think that CA certs will cause a false sense of security among less technically competent users
14:43 <+ryan-c> Jeremy_Rand: my main counterargument is that we have the opportunity to shape policy such that falsely issued certs are detectable and tlsa adoption is pushed forward, and if we do nothing they could just do something without our input.
14:45 <+ryan-c> my contact has significant influence with a couple industry groups, and could probably help us with some other things (like getting ietf to reserve .bit for us)
14:45 <@Jeremy_Rand> Is it likely that a CA would do something with .bit without our input, particularly if we had a policy against such things?
14:46 <+ryan-c> Jeremy_Rand: The initial response I got made it pretty clear if someone like facebook got a .bit site and wanted a cert for it, they'd try to do it.
14:46 <+ryan-c> Jeremy_Rand: It's at least plausible that it would happen despite our protests.
14:47 <@Jeremy_Rand> I just don't like being in a situation where we're encouraging users to trust a CA in connection with .bit
14:47 <@Jeremy_Rand> Because if someone gets owned as a result,
14:47 <@Jeremy_Rand> .bit will be blamed by some people
14:48 <+ryan-c> Jeremy_Rand: Your objection is noted. It would still be an improvement, the downside is that it's less of an improvement than it might appear to be.
14:48 <+ryan-c> Jeremy_Rand: encouraging users to trust a ca doesn't really matter anyway, nothing stopping a cert being issued right now.
14:49 <+ryan-c> jbisch, hl, cassiniNMC, opinions?
14:49 <@Jeremy_Rand> It's a worsening of the security offered by something based on Convergence or mitmproxy
14:49 <@Jeremy_Rand> if a proxy is validating .bit, then no CA can subvert it
14:50 <+ryan-c> Jeremy_Rand: even if CAs issue .bit certs a validating proxy prevents subversion.
14:51 <@Jeremy_Rand> ryan-c: right, but if CA validation is available, fewer users will go through the trouble of installing a proxy
14:51 <+ryan-c> Jeremy_Rand: It is less secure than a validating proxy, the question is whether it's better than nothing.
14:51 <@Jeremy_Rand> If we were comparing it to no TLS at all, it would be an improvement.  I am concerned that it would worsen adoption of validating proxies.
14:51 <@Jeremy_Rand> Which would be harmful overall
14:51 < indolering> Jeremy_Rand: community guidelines and the IETF spec are our only sources of leverage.
14:52 <+ryan-c> Jeremy_Rand: We are comparing it to nothing at all.
14:52 < indolering> IETF RFC*
14:52 < indolering> Sorry, my internet connection dropped
14:52 <+ryan-c> Jeremy_Rand: you need to count both users who would not otherwise use namecoin/.bit at all, and those who would, but won't use a proxy if they don't have to.
14:52 <@Jeremy_Rand> ryan-c: I'm not convinced that that's what we're comparing it to.  Because right now we have validating proxies, and if we discourage some users from installing them because CA's are easier, then that's harmful
14:53 <+ryan-c> Jeremy_Rand: I estimate that the first group is much larger than the second.
14:53 <+ryan-c> Jeremy_Rand: if the first group is larger enough than the second, the tradeoff is a good one.
14:53 <@Jeremy_Rand> Users who wouldn't use .bit unless there were a CA, are misguided and should be convinced by easier to use proxies
14:53 <+ryan-c> the question is what "larger enough" is.
14:54 <@Jeremy_Rand> the proxies in existence suck
14:54 <@Jeremy_Rand> making them better would improve adoption a lot
14:54 -!- Guest42715 [~Sleepnbum@pool-108-13-12-95.lsanca.fios.verizon.net] has joined #namecoin-dev
14:54 <@Jeremy_Rand> (and I say they suck despite being the maintainer of one)
14:55 <+ryan-c> Jeremy_Rand: Security is not the only concern we should consider. Namecoin and .bit are pointless if nobody uses them.
14:55 <+ryan-c> Jeremy_Rand: I don't really want to continue arguing with you about this though since I know there is no possible way to change your mind.
14:55 <@Jeremy_Rand> Nobody, would be pointless.  Some number less than ubiquitous, would not necessarily be pointless
14:56 <+ryan-c> I'm interested what other people think.
14:56 <+ryan-c> jonasbits, midnightmagic, hl, cassiniNMC, JohnKenney are any of you here?
14:57 < mnp> is there going to be an nmc application for key or certificate distribution ?
14:57 < mnp> ie, stuff a cert in a c/somesite.bit name?
14:57 <+ryan-c> mnp: we're supporting an analog of TLSA/DANE allowing ceritificate information to be included
14:58 < indolering> Jeremy_Rand: any backwards compatible slution (JSDNS or a .bit suffix) needs a CA to sign off on their cert.
14:58 <+ryan-c> mnp: it would be a fingerprint of the public key probably
14:58 < jonasbits> ryan-c: I think you should go ahead and talk to the CA guys
14:59 <+ryan-c> jonasbits: I already contacted them, to be clear, and they were way more interested than I thought. The guy I'm in contact with already thinks bitcoin and tor are awesome.
15:00 < jonasbits> The great thing with open source is we dont need to win, to "win" :-) Try everything, the future will decide
15:01 <@Jeremy_Rand> as ryan-c pointed out, we're at 3 hours now
15:02 <@Jeremy_Rand> are there opinions on when/if we should do another meeting?  Was this meeting generally helpful?
15:02 <@Jeremy_Rand> (I think it was helpful :-) )
15:02 < indolering> Me too.
15:02 < indolering> hl: could you write a blogpost on our options for light clients?
15:03 <@Jeremy_Rand> mnp: are you here because of the Reddit post?
15:03 < mnp> partly, ive been messing around with the core for a little while
15:04 <@Jeremy_Rand> cool
15:04 < jonasbits> Please have more meetings (with Internet Time @800 )
15:04 <@Jeremy_Rand> mnp: was this meeting good for you?
15:04 < cassiniNMC> Frequency: Every 1st and 3rd Saturday???
15:05 < mnp> yes, i scarfed a number of links at least.  that is one challenge: knowing who is working on what and where the code is
15:05 <@Jeremy_Rand> excellent
15:05 < mnp> a scoreboard somewhere prominant would be helpful
15:05 <@Jeremy_Rand> yeah
15:05 < mnp> status like "in progress", abandoned, future, etc
15:05 <@Jeremy_Rand> yeah
15:05 <+ryan-c> (to be a little more clear, when i said i didn't want to continue discussing with jeremy, it's because i don't think *either of us* has any arguments that will change the other's mind)
15:05 < indolering> You mean, a real roadmap?!
15:05 < indolering> :)
15:06 < mnp> well that implies committment to a direction, and it's okay not to have one
15:06 < mnp> as someone said above, try a few things and see what works is an okay plan sometimes
15:06 < indolering> Cool, let's call it done.
15:06 <@Jeremy_Rand> so, I polled all the major developers, and this timeslot was the best one.  Should we do every 2 weeks?  Or every 1st and 3rd Saturday as cassiniNMC suggested?
15:07 <+ryan-c> first and third is probably better than every other week
15:07 < jonasbits> +1
15:07 <@Jeremy_Rand> ok, 1st and 3rd Saturday, same start time as this one
15:07 < indolering> I'm not sure if monthly is really necessary, but it could help for people that miss one.
15:07 <+ryan-c> a bit easier to keep track of in a calendar
15:07 < indolering> Could we get someone to writeup a summary?
15:07 <+ryan-c> let's try to set some time limits and agenda ahead of time for the next one.
15:08 < indolering> Legally speaking, a summary is much preferred.
15:08 <@Jeremy_Rand> anyone volunteer for writing a summary?  Preferably post it on the forum and Reddit
15:08 < indolering> (advice from a lawyer on board meeting minutes)
15:09 < mnp> fine, i can 
15:09 <+ryan-c> indolering: except that we're conducting this on irc which must be assumed to be logged in full by multiple people.
15:09 < indolering> ryan-c: but it's an additional step.
15:09 < indolering> That requires time and effort.
15:10 -!- Guest42715 [~Sleepnbum@pool-108-13-12-95.lsanca.fios.verizon.net] has quit [Ping timeout: 256 seconds]
15:10 < indolering> And a summary would reduce the effort required for, say, Domob to keep up with things.
15:10 <+ryan-c> A summary is a good idea for many reasons, I just think that in this case, legal reasons are not included.
15:11 -!- Jeremy_Rand changed the topic of #namecoin-dev to: NEXT MEETING Jan 17 at 5PM UK time | Namecoin Development | Stable: https://github.com/namecoin/namecoin | http://namecoin.info | https://forum.namecoin.info/ | https://explorer.namecoin.info/
15:11 < cassiniNMC> BTW, would Sunday also be considered? I'm asking because in Europe
15:11 <+ryan-c> Jeremy_Rand: please change that to UTC rather than UK time.
15:11 <@Jeremy_Rand> ryan-c: UTC is confusing because it's not covered by daylight savings while UK time (and most other timezones) are
15:11 < cassiniNMC> a Saturday date is a Saturday evening in EU which is a bit awkward for some
15:12 < cassiniNMC> i.e. phelix, domob, snailbrain
15:12 <+ryan-c> Jeremy_Rand: That is the exact argument I would make as to why UK time is confusing.
15:12 <@Jeremy_Rand> cassiniNMC: yeah, there are no good times for everyone.  I polled all the devs and this was the best one (significantly)
15:13 <+ryan-c> Jeremy_Rand: not all countries change daylight savings time on the same dates or at all.
15:13 <@Jeremy_Rand> ryan-c: fair point
15:13 -!- Jeremy_Rand changed the topic of #namecoin-dev to: NEXT MEETING Jan 17 at 5PM UTC | Namecoin Development | Stable: https://github.com/namecoin/namecoin | http://namecoin.info | https://forum.namecoin.info/ | https://explorer.namecoin.info/
15:14 <+ryan-c> Jeremy_Rand: thanks
15:14 <@Jeremy_Rand> ok, so I'm going to go eat breakfast now :-)
15:14 <@Jeremy_Rand> see ya
15:15 <+ryan-c> yeah, me too
15:15 < indolering> Peace