fsb4000 (OP)
Legendary
 Offline
Activity: 1400
Merit: 1000
|
 |
January 03, 2015, 10:15:09 PM |
|
Лог обсуждения, если кто-то не смог зайти в указанное время, но хотел бы узнать что было. [23:01] <@Jeremy_Rand> Hello everyone
[23:01] <@Jeremy_Rand> we'll be starting the meeting shortly
[23:02] <@Jeremy_Rand> Okay, so we'll be moderating the channel, and then allowing questions/comments from everyone periodically
[23:03] == open_moon [458e891b@gateway/web/freenode/ip.69.142.137.27] has joined #namecoin-dev
[23:03] <@Jeremy_Rand> I think Luke-Jr requested a ping when the meeting starts, so that has now happened
[23:03] <Luke-Jr> ..
[23:04] <Luke-Jr> why is the channel being +m'd?
[23:04] <@Jeremy_Rand> Luke-Jr: how about we don't do that and we only do it if it becomes too noisy
[23:04] <Luke-Jr> +1
[23:05] <@Jeremy_Rand> ok, so as long as it's not noisy we'll stay unmoderated
[23: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)
[23: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
[23:06] <@Jeremy_Rand> But I can tell you informally that Namecore is progressing :-)
[23: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?
[23: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?)
[23:07] <+ryan-c> (I owe hl some updates to that about models that don't include currency transactions)
[23:08] <@Jeremy_Rand> in particular, hl indolering jbisch JohnKenney , are you guys here?
[23:08] <+ryan-c> JohnKenney, midnightmagic, cassiniNMC, hl, indolering, jbisch?
[23:08] <hl> I'm here.
[23:08] <indolering> Hey
[23:08] <cassiniNMC> hi
[23:08] <jbisch> here
[23:08] <mnp> chime
[23:09] <indolering> mime
[23:09] * indolering is trapped in an invisible box.
[23:09] <+ryan-c> indolering: ಠ_ಠ
[23:09] <@Jeremy_Rand> ok, so if hl can fill people in on the lightweight client stuff, that would be most awesome
[23:10] <hl> Sure.
[23:10] <@Jeremy_Rand> (also, relevant link: https://github.com/hlandau/ncdocs/blob/master/stateofnamecoin.md )
[23:10] <indolering> ryan-c: you have something against mimes? My family has been miming for 6 generations.
[23:10] <@Jeremy_Rand> and https://github.com/hlandau/ncdocs/blob/master/nctypes-intro.md
[23:10] <indolering> Sprry, go ahead hl
[23:10] <indolering> Sorry*
[23:10] <hl> OK.
[23:13] == pmc [~peter@p20030058A572B6A61ACF5EFFFED5F9BE.dip0.t-ipconnect.de] has joined #namecoin-dev
[23: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.
[23: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.
[23:15] <indolering> The name database records are compressible enough to be trivial in size.
[23:15] <@Jeremy_Rand> indolering: at current usage levels, correct?
[23:15] * indolering did some playing around with record sizes and compression.
[23:15] <mogreen> I'm here, chime
[23:15] <+ryan-c> hl: was that with or without namespace filtering?
[23:15] <indolering> No, it can scale to .info and .biz records.
[23: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".
[23:15] <indolering> levels*
[23:16] <indolering> Although that depends on us pushing nameservers pretty heavily, but that should be the norm anyway.
[23:17] <@Jeremy_Rand> indolering: I'd have to disagree there, nameservers have some disadvantages
[23: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.
[23:17] <@Jeremy_Rand> but anyway
[23:18] <indolering> Well, it's akin to storing full keys on id/ records.
[23:18] <@Jeremy_Rand> My understanding is that Bitcoin is considering something like UTXO CB in the future?
[23:18] <hl> I think so, yes.
[23:19] <@Jeremy_Rand> Is Luke-Jr able to comment on that?
[23:19] <indolering> The only time it makes a lot of sense is for hidden services.
[23: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.
[23:19] <@Jeremy_Rand> indolering: the Google DNS guy I talked to had a use case that would be broken by nameservers
[23:19] <+ryan-c> and that works having only the last 36k block headers
[23:19] <JohnKenney> hi
[23: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
[23:20] <indolering> Jeremy_Rand: forum post?
[23:20] <hl> transaction containing the attested tree root, a Merkle branch proving inclusion of that in a block, and the corresponding block header.
[23: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.
[23:21] <+ryan-c> hl: how does that prevent someone from getting a false negative?
[23:21] <hl> A lightweight client would trust the UTXO CB root contained in the block at a threshold depth.
[23:22] <@Jeremy_Rand> So, this gets into the idea of a separate Merkle tree for the name database
[23:22] <@Jeremy_Rand> Which hl has been informally calling UXNO
[23:22] <@Jeremy_Rand> for UneXpired Name Operation
[23: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.
[23:23] <hl> So you'd get a Merkle branch for 'There are no names between aaa and bbb, so aab doesn't exist'
[23:23] <+ryan-c> okay
[23:23] <hl> I call this NX CB, or in conjunction with UTXO CB, UTXO CB+NX CB.
[23:23] <hl> This would be a separate root stored in the coinbase.
[23:24] <hl> While authenticated denial of existence is desirable, I think it's a lower priority than the affirmative security provided by UTXO CB.
[23: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)
[23:24] <hl> Ah, right.
[23:24] <@Jeremy_Rand> (I realize that names are trivial, but it's good for messaging to have a good name early)
[23: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.
[23:25] <@Jeremy_Rand> I dislike using the word "unexpired" because expired means <36k blocks old, while unspent means <36k blocks AND not updated later
[23:25] <hl> Now, once a name expires, its coin is marked spent. So for this reason, UTXO and UXNO actually are very similar.
[23:26] <@Jeremy_Rand> right, I view unspent as a slightly more restrictive condition than unexpired
[23: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.
[23:27] <jbisch> Jeremy_Rand: Don't you mean expired means >36k blocks old?
[23:27] <@Jeremy_Rand> jbisch: you're right, I meant to type "unexpired"
[23:27] <hl> Anyway, I think there are a few unresolved issues preventing use of SPV36 or UTXO CB.
[23: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.
[23:28] <hl> ryan-c: Are you sure about this? The wire protocol doesn't have a get tx by name command, does it?
[23:28] <@Jeremy_Rand> hl: yeah, UTXO is higher priority than secure denial of existence
[23:28] <@Jeremy_Rand> but we should do both eventually
[23:28] <@Jeremy_Rand> (IMO)
[23:28] <hl> Yeah.
[23:28] <mnp> has anyone thought about something of a merkle tree and skip list hybrid?
[23:29] <hl> Elaborate?
[23:29] <@Jeremy_Rand> mnp: can you elaborate?
[23:29] <+ryan-c> hl: name_history lets you get a tx by name.
[23:29] <mnp> ie don't hash everything on the way to cb, but just some subset, say every N on the way
[23:29] <+ryan-c> hl: oh, the wire protocol? no.
[23:29] <hl> ryan-c: But we're talking SPV, i.e. a headers-only client here...
[23:30] <hl> ryan-c: Enabling SPV for namecoin would require a new wire protocol command.
[23:30] <+ryan-c> hl: It could be over a separate comms channel
[23:30] <@Jeremy_Rand> mnp: can you explain how that is beneficial?
[23:31] <mnp> if you look at the vanilla skip list https://upload.wikimedia.org/wikipedia/commons/8/86/Skip_list.svg
[23: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
[23: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
[23:32] <hl> generate proofs of inclusion ala Merkle branches is preserved.
[23:33] <@Jeremy_Rand> hl: have you looked at the stuff that maaku is working on for Bitcoin?
[23:33] <hl> Not sure. I've glanced at the authenticated prefix trees spec, which looks promising.
[23:33] <hl> Anyway, there is a second issue.
[23: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.
[23: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.
[23: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
[23:35] <hl> required.
[23:36] <hl> As I've explained, I think authenticated denial of existence and UTXO CB are almost completely orthogonal. They can be implemented separately.
[23: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.
[23: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
[23:36] <hl> Right. Standardising on 12 would probably make sense, yes.
[23: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.
[23:37] <hl> Yeah, pretty much. Though it might be possible if you had some particularly weird name using imports.
[23:38] <indolering> i.e. it's okay to wait until we have more engineer resources.
[23:38] <hl> Yeah.
[23:38] <@Jeremy_Rand> Agreed, it's important long term, but not an immediate concern IMO
[23:38] <indolering> engineering*
[23:39] <hl> The other issue is privacy. None of this preserves privacy for name requests, since resolution requires other nodes to be queried.
[23:40] <@Jeremy_Rand> right, for privacy you can still make optimizations though
[23:40] <@Jeremy_Rand> e.g. only receive the last 36k blocks
[23:40] <indolering> That is also an orthogonal issue.
[23:40] <@Jeremy_Rand> indolering: well, it's a relevant scalabliity optimization
[23:40] <indolering> Jeremy_Rand: agreed.
[23:41] <hl> If you're going to do that, you may as well just do the trimmed-UTXO mode.
[23: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)
[23:41] <indolering> I've got some ideas, but I need to vet them a bit more before suggesting it publicly.
[23:41] <indolering> them*
[23:41] <hl> Oh, getheaders is in now? That's good, I was worried that was going to break the network once namecore became a thing.
[23:42] <+ryan-c> hl: We should standardize on 12 blocks.
[23:42] <hl> ryan-c: Yeah.
[23:42] <@Jeremy_Rand> hl: getheaders was readded in 0.3.80, I think
[23:42] <@Jeremy_Rand> Daniel would know for sure
[23: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
[23:42] <@Jeremy_Rand> ryan-c: that's correct
[23:42] <indolering> FWIW, I think there is funding out there to fix the privacy issue.
[23:43] <+ryan-c> but we already have a case where miners able to mine 12 blocks in a row can do nasty things.
[23:43] <indolering> Ethereum is interested in funding something.
[23:43] <@Jeremy_Rand> indolering: privacy is only an issue if full blocks aren't received
[23:43] <+ryan-c> so i think just saying that's our security level is fine.
[23:43] <indolering> Yeah.
[23:43] <indolering> Full blocks for all names.
[23:43] <+ryan-c> if 12 block security level bothers someone, they can run a full node
[23:43] <@Jeremy_Rand> and 36k blocks still isn't that much network usage
[23:44] <indolering> Jeremy_Rand: agreed, hence the need for more vetting : )
[23:44] <@Jeremy_Rand> Is anyone interested in trying to implement a client mode that only downloads the last 36k blocks?
[23:45] <@Jeremy_Rand> I guess the first issue there would be having a client that uses getheaders
[23:45] <jbisch> You mean like is someone interested in doing the programming?
[23:45] <@Jeremy_Rand> jbisch: yes
[23:45] <hl> I call that FN36. But is there a point relative to UTXO-trimming mode?
[23:45] <jbisch> I guess I might.
[23:45] <@Jeremy_Rand> Namecore uses getheaders, does any other client software for Namecore do that? I don't believe libcoin does
[23:45] <@Jeremy_Rand> for Namecoin*
[23: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.
[23:46] == pmc [~peter@p20030058A572B6A61ACF5EFFFED5F9BE.dip0.t-ipconnect.de] has quit [Quit: Konversation terminated!]
[23:46] <+ryan-c> privacy conscious users can use tor to connect to namecoin as a mitigation
[23:46] <@Jeremy_Rand> ryan-c: right, the SPV privacy isn't an issue if you're using Tor
[23:46] <@Jeremy_Rand> or rather, it's less of an issue
[23: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...
[23:46] <@Jeremy_Rand> you need to handle stream isolation properly
[23:46] <@Jeremy_Rand> I don't know if Bitcoin does stream isolation in a safe way
[23:46] <@Jeremy_Rand> I doubt it
[23:47] <+ryan-c> Jeremy_Rand: bitcoin actually supports nodes running on hidden services
[23:47] <+ryan-c> Jeremy_Rand: Is stream isolation applicable for long lived connections?
[23: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 ?
[23: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
[23:48] <+ryan-c> Jeremy_Rand: what?
[23:49] <+ryan-c> indolering: should be 0.3.80, please fix
[23:49] <@Jeremy_Rand> ryan-c: ideally you want to establish separate hidden service connections for different identities
[23:49] <@Jeremy_Rand> otherwise the hidden service operator can tell that two requests were the same user
[23:49] <+ryan-c> Jeremy_Rand: You mean querying the same node for multiple different .bit domains?
[23:49] * indolering is changing it now.
[23:49] <+ryan-c> Jeremy_Rand: I do not think this is a problem bitcoin has
[23: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)
[23:50] <@Jeremy_Rand> It's an issue for Bitcoin too
[23:50] <@Jeremy_Rand> because it links ownership of coins
[23:51] <@Jeremy_Rand> but I'm guessing they haven't dealt with that
[23:51] <@Jeremy_Rand> seeing as there are easier ways to link coins
[23:51] <+ryan-c> Jeremy_Rand: I think that would require frequently rotating what nodes one is connected to.
[23:51] <+ryan-c> Jeremy_Rand: which would fall over real quick for high rate of lookups
[23:52] <@Jeremy_Rand> ryan-c: yep, Tor changes the entire circuit for each identity
[23:52] <@Jeremy_Rand> ryan-c: no, it wouldn't be per domain
[23:52] <@Jeremy_Rand> it would be per identity
[23:52] <@Jeremy_Rand> as per the SOCKS proxy username/password that Tor receives
[23:52] <+ryan-c> Jeremy_Rand: but then namecoin would need a concept of identity
[23:53] <@Jeremy_Rand> ryan-c: you can get that from TorBrowser if you have a proxy between TorBrowser and Tor
[23:53] <@Jeremy_Rand> which you probably need anyway if you're doing .bit to .onion
[23:53] <@Jeremy_Rand> basically Namecoin would have an argument for name_show
[23:53] <+ryan-c> Jeremy_Rand: but namecoin doesn't support identities
[23:54] <@Jeremy_Rand> which would be an indentity
[23:54] <+ryan-c> yes, it would need an argument to name_show
[23:54] <@Jeremy_Rand> and Namecoin would maintain separate peer connections per identity
[23:54] <+ryan-c> probably something to implement "in the future"
[23:54] <@Jeremy_Rand> right, it's important if we care about browsing anonymity
[23:54] <@Jeremy_Rand> which we will at some point
[23:54] <@Jeremy_Rand> but it's not a huge priority since right now we don't even work with TorBrowser at all
[23: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"
[23:55] <hl> So it would be nice to solve, but shouldn't be a priority.
[23:55] <@Jeremy_Rand> hl: turns out that it's attackable pretty often, the Tor guys spent a lot of effort fixing that
[23:55] <@Jeremy_Rand> depends on your threat model obviously
[23:55] <hl> Hmm.
[23:55] <@Jeremy_Rand> for Tor's threat model it matters
[23:56] <@Jeremy_Rand> Let's say that ilovehellokitty.bit is only visited by 2-3 people
[23:56] <@Jeremy_Rand> and wikileaks.bit is visited by a lot of people
[23: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
[23:57] <mnp> right, they call that traffic analysis. timing is also considered
[23:57] <@Jeremy_Rand> yep
[23: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.'
[23:57] <@Jeremy_Rand> hl: you can correlate with external info
[23:57] <@Jeremy_Rand> and keep in mind that one of the websites might be evil too
[23:58] <hl> Hmm....
[23:58] <@Jeremy_Rand> let's say wikileaks.bit is a scam site entrapping whistleblowers
[23:58] <@Jeremy_Rand> and they also are controlled by the same guy who sees you contact both wikileaks.bit and ilovehellokitty.bit
[23:59] <@Jeremy_Rand> now they have a lot of evidence for exactly who connected to wikileaks.bit, combined with what was uploaded to it
[23:59] <+ryan-c> Jeremy_Rand: or they just drop an 0day on the visitors who upload things
[23:59] <hl> And the resolver circuit and the wikileaks circuit can be correlated?
[23:59] <mnp> you have to assume isp data is in the clear
[23:59] <@Jeremy_Rand> yes, if nothing else based on timing
[00:00] <hl> Hmm, yes.
[00:00] <@Jeremy_Rand> This seems like something that would be nice to get merged into Bitcoin if we do fix it
[00:00] <@Jeremy_Rand> because linking coins sucks
[00:01] <@Jeremy_Rand> ok, so
[00:02] <@Jeremy_Rand> what are the barrier to implementing a 36k FN client?
[00:02] <@Jeremy_Rand> What existing Namecoin client implementations can handle getheaders at the moment?
[00:03] <@Jeremy_Rand> Namecore is one
[00:03] <@Jeremy_Rand> (by handle, I mean sync using)
[00:03] <@Jeremy_Rand> hl: did you do something with btcd?
[00: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.
[00: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
[00:06] <@Jeremy_Rand> but, I don't have an ETA on when I might be able to do that with libcoin
[00:06] <@Jeremy_Rand> hl: how suitable is the btcd codebase for a 36k FN client?
[00:06] <@Jeremy_Rand> (preferably pruning non-name transactions)
[00:07] <jbisch> indolering: You are so close with the blog post title. Just add a 0. in front of the 3.80.
[00: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.
[00:08] <indolering> jbisch: derp
[00: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?
[00:09] <hl> Sure.
[00:09] <@Jeremy_Rand> sounds like a plan
[00: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)
[00:09] <@Jeremy_Rand> ok, so
[00:10] <@Jeremy_Rand> next order of business: NMControl
[00: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
[00:11] <@Jeremy_Rand> Anyone here who likes DNS and Python who'd like to implement that?
[00:12] <@Jeremy_Rand> heh, no takers? :-)
[00:12] <mnp> in namecore?
[00:12] <@Jeremy_Rand> mnp: in NMControl, it's the .bit parser, written in Python
[00:12] <@Jeremy_Rand> Namecore only deals with the name/value system generally; everything .bit related is in NMControl
[00:13] <@Jeremy_Rand> indolering: were you talking to sdgathman about doing that at some point?
[00:13] <indolering> He was interested in porting over unit tests.
[00:14] <indolering> I wouldn't mind taking a stab at it, but I have very little experience with both Python an DNS.
[00: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
[00:15] <@Jeremy_Rand> I prefer not to do it myself, as my low-level DNS skills are kind of sketchy
[00:15] <indolering> Jeremy_Rand: Yeah, that would be you, hl, and sdgathman :P
[00:15] <jbisch> I know Python, but probably not DNS enough.
[00:15] <@Jeremy_Rand> hl: would you be up for checking indolering's work if he implements it?
[00:16] <@Jeremy_Rand> or we could ask sdgathman, but he's not here rihgt now
[00: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.
[00: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
[00:17] <indolering> We wanted to convert NMControl to python 3, should we do that first?
[00:18] <indolering> And do we have proper unit testing on NMControl?
[00:18] <+ryan-c> Jeremy_Rand: I can check his work.
[00: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
[00:18] <+ryan-c> I know DNS pretty well.
[00:18] <@Jeremy_Rand> but I'm totally fine with Python 3
[00: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.
[00:18] <@Jeremy_Rand> it would be a big endeavor though
[00:18] <indolering> Waiting only makes it bigger.
[00:19] <+ryan-c> Jeremy_Rand: There are still a lot of modules that don't work in python 3
[00:19] <indolering> It is technical debt, loads of it.
[00:19] <indolering> ryan-c: Any that are important to NMControl?
[00: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
[00:19] <@Jeremy_Rand> PyDNS and PyMDS don't support DNSSEC and haven't been subject to nearly any auditing
[00:20] <+ryan-c> unbound is a good idea
[00:20] <hl> Are you using PyDNS/PyMDS just for wire protocol encoding, or for logic on top of that?
[00: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
[00:21] <@Jeremy_Rand> but I really want to scrap everything that uses them
[00:21] <hl> Ah. I can see that, yeah.
[00:22] <hl> Especially if it's acting as a recursive resolver.
[00:22] <@Jeremy_Rand> yeah
[00:22] <@Jeremy_Rand> it's a mess
[00:22] <indolering> Also, I would prefer to implement a more modular system of translation based on transports.
[00:22] <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.
[00:23] <indolering> If I understand the task correctly, I'm basically writing a d/ record -> DNS record converter.
[00:23] <@Jeremy_Rand> hl: I really don't like writing libraries that we have to maintain ourselves, however minimal they are
[00:23] <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.
[00:24] <@Jeremy_Rand> hl: are you sure? What kind of failures would be plausible?
[00:24] <indolering> But we also have to handle Tor, i2p, http, etc, etc.
[00:24] <hl> Jeremy_Rand: Not sure? I guess if you stick to safe Python and handle exceptions it should be fine.
[00:25] <hl> It also forces rather tight couping and the use of Unbound.
[00: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
[00:25] <@Jeremy_Rand> Well, right now we're forcing use of PyDNS and PyMDS
[00:26] <@Jeremy_Rand> I'd rather force Unbound than that
[00:26] <@Jeremy_Rand> and I'd rather force Unbound than some other library that we wrote ourselves
[00:26] * Jeremy_Rand has bad experience with building stuff himself
[00:26] <hl> True enough.
[00:27] <+ryan-c> parsing dns ourselves is a terrible idea
[00:27] <+ryan-c> emitting dns records is a kinda bad idea
[00:27] <+ryan-c> er
[00:27] <+ryan-c> implementing our own thing to generate dns wire data
[00:28] <@Jeremy_Rand> yeah, I've seen too many failures to properly implement edge cases even in simple protocols
[00:28] <+ryan-c> Jeremy_Rand: did you know that dns has some very limited built in support for compression?
[00:28] <@Jeremy_Rand> ryan-c: that sounds like it could end badly
[00:29] == deepy [deepy@acehack.de] has quit [Quit: ZNC - http://znc.in]
[00:29] <@Jeremy_Rand> ok, so indolering can play around with converting d/ to DNS in an RPC call; ryan-c can check his work?
[00:30] <+ryan-c> that is the plan
[00:30] <@Jeremy_Rand> ok. So, related task: format validation
[00:30] <@Jeremy_Rand> NMControl will spit out whatever text is in an "ip" record for example
[00:30] <+ryan-c> Jeremy_Rand: (not really relevent, but...) http://www.tcpipguide.com/free/t_DNSNameNotationandMessageCompressionTechnique.htm (note that it's three pages)
[00:30] <@Jeremy_Rand> even if it's not an IP address
[00:30] <@Jeremy_Rand> this needs to be fixed
[00:31] <@Jeremy_Rand> basically all of the RPC calls should not output data that's clearly malformed
[00:31] <+ryan-c> that is a good idea
[00:31] <@Jeremy_Rand> like the idiot who's shoving Bitmessage addresses into a "translate" field
[00:32] <@Jeremy_Rand> Do we have any volunteers who would like to implement such validation?
[00:32] == Guest58546 [znc@acehack.de] has joined #namecoin-dev
[00:32] <indolering> Jeremy_Rand: I'm pretty sure that would fall to me.
[00:33] <@Jeremy_Rand> indolering: go for it :-)
[00:33] <+ryan-c> i will help indo regular expression
[00:33] <@Jeremy_Rand> yay
[00:33] <indolering> I've already spent a lot of time on this task, both research wise and implementing checks for Speech.is.
[00:33] <@Jeremy_Rand> cool
[00:34] <@Jeremy_Rand> ok, next up -- jbisch has been porting NMControl to Android... jbisch can you tell us about how that's going?
[00:35] <indolering> I would prefer using a PEG.
[00:35] <indolering> Whoa, can we cover Python 2 to 3 first?
[00:36] <@Jeremy_Rand> um, sure, I guess
[00:36] <@Jeremy_Rand> I'm fine with Python 3... phelix isn't here and he had some objections to it
[00:37] <@Jeremy_Rand> if someone wants to run NMControl through a converter and see how much stuff needs manual changing, that would be interesting
[00: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?
[00:37] <jbisch> Me
[00:38] <jbisch> Most of the stuff is usually not too hard.
[00:38] <indolering> Jeremy_Rand: I tried that but I had trouble with 2to3's reporting.
[00: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
[00:38] <indolering> jbisch: want to work together on that?
[00:38] <jbisch> indolering: Sure.
[00:38] <@Jeremy_Rand> ok great
[00:38] <@Jeremy_Rand> anything else before we move on to Android?
[00:38] <indolering> I have an idea of what needs to be replaced, if you can handle checking the 2to3 output.
[00:38] <indolering> No, go ahead.
[00:39] <@Jeremy_Rand> ok, so can jbisch tell us about how the Android port is going?
[00:39] <jbisch> First the link to the code: https://github.com/josephbisch/nmcontrolandroid
[00: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.
[00:40] <jbisch> Can't do anything practical with just the android device until a proxy is implemented into nmcontrol.
[00:41] <@Jeremy_Rand> jbisch: can you access the NMControl DNS from Android?
[00:41] <@Jeremy_Rand> (I realize that would probably require root)
[00:41] <jbisch> Not unless you are rooted, because you need to run on port 53.
[00:41] <+ryan-c> could run on 5353
[00:42] <@Jeremy_Rand> I mean, lots of people root their Android phones, is that a big dealbreaker?
[00: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.
[00:42] <jbisch> Android doesn't let you set the dns with a port afaik.
[00:42] <+ryan-c> do we need dns for android?
[00:43] <+ryan-c> as a service?
[00: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
[00:43] <+ryan-c> we could just provide a proxy
[00:43] <@Jeremy_Rand> ryan-c: right, that gets to my interest in mitmproxy
[00:44] <@Jeremy_Rand> which is actually on my list of things to bring up, but a bit further down
[00:44] == Guest58546 [znc@acehack.de] has quit [Quit: ZNC - http://znc.in]
[00: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
[00:44] <+ryan-c> providing a proxy means not needing root (i think)
[00:45] <@Jeremy_Rand> ryan-c: that's correct, although you need to configure apps to use the proxy
[00:45] <@Jeremy_Rand> Orbot benefits from root because then it can use a transparent proxy
[00:45] <jbisch> Yes, you don't need root if you have a proxy. You can, for example, use Firefox.
[00:46] <@Jeremy_Rand> ok, so since that has come up, let's discuss that now
[00:46] <@Jeremy_Rand> right now the proxy implementation we're using on PC's is Convergence
[00:46] <@Jeremy_Rand> it's kind of nice in that it can do TLS validation
[00:46] <@Jeremy_Rand> but it's Javascript
[00:47] <@Jeremy_Rand> and isn't really maintained at this point
[00:47] == deepa [deepy@acehack.de] has joined #namecoin-dev
[00: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
[00:47] <@Jeremy_Rand> mitmproxy is exactly that
[00:47] <@Jeremy_Rand> it's actively maintained
[00:48] <@Jeremy_Rand> and the mitmproxy devs seem quite willing to assist us in whatever we need
[00:48] <@Jeremy_Rand> I would support using mitmproxy, I think indolering said he agrees
[00:49] <@Jeremy_Rand> Ryan expressed some concerns about it -- Ryan would you like to comment on that now?
[00: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.
[00: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.
[00:51] <+ryan-c> I haven't dug around much in the code to see if there's anything else to be concerned about
[00: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
[00:51] <+ryan-c> but those problems shoudln't be that hard to fix
[00:51] <@Jeremy_Rand> Max doesn't think it will be hard to make it suitable for us
[00:52] == jonasbits [~quassel@78-73-105-79-no162.tbcn.telia.com] has joined #namecoin-dev
[00:52] <+ryan-c> we also probably should add the ability to only intercept ssl for specific TLDs
[00: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?
[00:52] <+ryan-c> there's also the no client certs when intercepting thing, but hardly anything uses client certs
[00:53] <+ryan-c> Jeremy_Rand: Not that I'm aware of.
[00:53] <@Jeremy_Rand> ryan-c: and yes, we should only terminate TLS for .bit
[00:53] <@Jeremy_Rand> ok, so is it okay in your opinion to use mitmproxy on the condition that we get the relevant features added?
[00:54] <+ryan-c> Jeremy_Rand: we should also look at SSLBump.
[00:54] <+ryan-c> (part of squid)
[00:54] <+ryan-c> it has some nice things like 'error condition mirroring'
[00:55] <+ryan-c> in general it will generate certificates that better match the presented ones
[00: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
[00:55] <@Jeremy_Rand> I Googled for it and the URL was already in my recent history
[00:55] <@Jeremy_Rand> so I know I looked at it recently
[00:55] <+ryan-c> Jeremy_Rand: well, we can always just lift algorithms from it.
[00:55] <+ryan-c> Jeremy_Rand: x509 is a bitch to get right
[00:56] <@Jeremy_Rand> yeah, I'm totally fine with borrowing algos from Squid
[00:56] <@Jeremy_Rand> so is mitmproxy approved then?
[00:56] <+ryan-c> i suppose
[00:57] <@Jeremy_Rand> yay
[00:57] <@Jeremy_Rand> anything else about the proxy stuff before we move on to Armory?
[00:58] <@Jeremy_Rand> ok, I guess we're moving on to Armory
[00:58] <@Jeremy_Rand> jbisch has been porting Armory to Namecoin
[00:58] <@Jeremy_Rand> jbisch: do you want to tell us how that's going?
[00:59] <jbisch> I am on my phone now, so I won't link.
[00:59] <@Jeremy_Rand> ok
[00:59] <jbisch> I have basic support, which is sending and receiving namecoins but not namrs.
[01:00] <jbisch> idk any questions?
[01:00] <@Jeremy_Rand> Do I understand correctly that Alan is willing to merge in the future, but not now?
[01:01] <jbisch> yes, they are just too busy with funding and enterprise customer features, but yes in the future.
[01: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?
[01:02] <jbisch> Just the tests need to be working and we need more people testing with testnet namecoins. Just me and one person tested.
[01:03] * indolering needs to work on the UI.
[01:03] <@Jeremy_Rand> ok
[01:03] <@Jeremy_Rand> does anyone here volunteer to test with some testnet namecoins?
[01:03] <jonasbits> I think im the extra person :-)
[01:03] <jbisch> yes you are
[01:03] <mnp> i can play with it also
[01:03] <@Jeremy_Rand> excellent
[01: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
[01:05] <@Jeremy_Rand> once NMControl has the necessary features I would love some feedback on my UI
[01:05] <indolering> Jeremy_Rand: okay.
[01:05] <@Jeremy_Rand> ok, anything else with Armory?
[01: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.
[01:06] <jbisch> I don't think so.
[01:06] <indolering> bad = requires understanding of implementation
[01:06] <@Jeremy_Rand> ok, so
[01:06] <indolering> That being said, it should still be as good as possible.
[01:06] <@Jeremy_Rand> next topic: namecoin.info and HTTPS
[01:06] <indolering> It's just a lower priority for me.
[01:06] <indolering> Yay!
[01: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
[01:07] <@Jeremy_Rand> is there something more than that that I don't know about?
[01:07] <indolering> ryan-c: that's your cue.
[01:07] <+ryan-c> Jeremy_Rand: Yeah, I should have done that by now but haven't.
[01:07] <+ryan-c> Jeremy_Rand: No, I've just been busy. :-/
[01: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
[01:08] <+ryan-c> mostly holidays and wedding planning, work has lightened up.
[01:08] <@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
[01:09] <+ryan-c> also some other personal stuff that is now sorted.
[01:09] <@Jeremy_Rand> (I don't mean that in a mean way :-) )
[01: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.
[01:10] <+ryan-c> no offense taken
[01:10] <@Jeremy_Rand> ok
[01:10] <@Jeremy_Rand> :-)
[01:10] <@Jeremy_Rand> anything else about the website before we move on to a new topic?
[01:10] <+ryan-c> no, i think i have everything needed
[01:10] <@Jeremy_Rand> ok
[01:10] <@Jeremy_Rand> so next topic: funding
[01:11] <@Jeremy_Rand> I have several hundred USD which is earmarked for Namecoin bounties, but must be committed to specific tickets before mid-March
[01:11] <@Jeremy_Rand> suggestions on things I should sponsor?
[01:12] <indolering> Jeremy_Rand: what are the restrictions on spending?
[01: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.
[01:12] <indolering> I suggested we use it to pay for namecoin.org or TLS certs but you mentioned some restrictions....
[01:13] <+ryan-c> Jeremy_Rand: we could break those down into smaller tasks.
[01:13] <mnp> anybody want to comment on namecore vs libcoin as a prio moving forward?
[01: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
[01:14] <+ryan-c> mnp: domob has been working on that and he isn't here right now, not sure how familiar anyone else is.
[01:15] <jonasbits> I would like to see a Testnet Block Explorer
[01: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
[01:15] <indolering> We could ask Namecha.in to do that.
[01:15] <+ryan-c> jonasbits: I would suggest we ask namecha.in to add one.
[01:15] <indolering> We also need them to start tracking miner ratios.
[01:16] <@Jeremy_Rand> libcoin is much easier to adapt for e.g. pruned databases
[01:16] <indolering> And IP addresses of mined blocks.
[01:16] <@Jeremy_Rand> so for lite client stuff libcoin is really nice
[01:16] <jonasbits> That would be great if they could be convinced
[01:16] <+ryan-c> jonasbits: I have access to the old explorers that khal wrote, but the code is pretty messy.
[01:16] <@Jeremy_Rand> I would like to have an open source block explorer
[01:16] <@Jeremy_Rand> that handles names
[01:16] <indolering> Jeremy_Rand: would that fall under "misc" or development?
[01:16] <@Jeremy_Rand> I could put a bounty on that if it would be helpful.
[01:16] <+ryan-c> Jeremy_Rand: ask khal if i can open source his, i have the code.
[01:16] <@Jeremy_Rand> That would be development
[01:17] <+ryan-c> Jeremy_Rand: also ask namecha.in
[01:17] <+ryan-c> Jeremy_Rand: we could also adapt insight pretty easy
[01:17] <jonasbits> ryan-c: insight would be great if it could be done
[01:18] <@Jeremy_Rand> ok
[01:18] <+ryan-c> indolering: If anyone wants to set up a website tracking miner ratios I'll share my code with them.
[01:18] <+ryan-c> it emits json
[01:18] <@Jeremy_Rand> I'm not sure I want to bother khal again, I felt really weird contacting him at work
[01:18] <+ryan-c> so really all it needs is visualication
[01:18] <cassiniNMC> namecoin.webbtc.com used to have a testnet explorer IIRC,
[01:18] <cassiniNMC> it is frozen ATM, though
[01: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
[01:19] <jonasbits> cassiniNMC: yea i remember that, but could not find it when i needed to use one
[01: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?
[01: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)
[01:20] <+ryan-c> indolering: Tell them I have patchs for looking at merged mining info for pool attribution that i can give them
[01:20] <indolering> ryan-c: If my memory serves me correctly, you still have a rather large "unknown" percentage.
[01:21] <+ryan-c> indolering: we do not
[01:21] <indolering> Okay.
[01:21] <+ryan-c> indolering: it was 1-2% unknown
[01:21] <indolering> ryan-c: great!
[01:21] <+ryan-c> indolering: I can identify all the pools blockchain.info does
[01:22] <indolering> ryan-c: okay.
[01:22] <@Jeremy_Rand> anything else about funding that we should talk about?
[01:22] <+ryan-c> what happened with discus fish?
[01:23] <indolering> ryan-c: we get 20KNMC
[01:23] <@Jeremy_Rand> ryan-c: not sure, Daniel would be the person to ask about that
[01:23] <+ryan-c> okay
[01:23] <indolering> Not sure about the bonus
[01:23] <indolering> Shuttleworth turned us down, but I messed up when I initially applied and had to redo everything in 24/hours.
[01:23] <indolering> And DNSChain fucking applied as well so they were confused.
[01:23] <indolering> So I am going to reapply.
[01:24] <indolering> I've got grant requests out for NLNet and the OpenTechFund.
[01: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
[01:24] <indolering> Should be hearing from them soon.
[01:24] <+ryan-c> okay
[01:24] <+ryan-c> next?
[01:24] <indolering> I'm flying to Virginia tomorrow to meet with the BitShares team.
[01:24] <indolering> They might have funding.
[01:24] <indolering> But that's still very preliminary.
[01:24] <indolering> But yeah, next.
[01:24] <+ryan-c> didn't they already go back on a funding promise already?
[01:25] <+ryan-c> doesn't matter
[01: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?
[01:25] <indolering> ryan-c: yeah, it's complicated.
[01:25] <indolering> They are paying me to fly out so ....
[01:26] <cassiniNMC> 0.3.80 for mac...
[01:26] <@Jeremy_Rand> ok yeah, so what's going on with that?
[01:26] <cassiniNMC> i need to get in touch with jedimstr, who
[01:26] <cassiniNMC> is the one with a non-SSE4 mac
[01:27] <@Jeremy_Rand> ok
[01:27] <cassiniNMC> Haven't heard anything from his tests during the last days,
[01:27] <@Jeremy_Rand> anything else?
[01:27] <cassiniNMC> however, today I pinged his client with a version and a getheaders message,
[01:27] <jonasbits> my mac is from 2006 if that is any help
[01:28] <cassiniNMC> and it replied with version = 38000 and a nicely formatted headers reply.
[01:28] <cassiniNMC> jonasbits: can it do Yosemite?
[01:29] <jonasbits> cassiniNMC: no im stuck at Leon
[01:29] <cassiniNMC> In this case it doesn't help us
[01:30] <cassiniNMC> While we have indo around ... indolering: have you had a look at the betabuild I sent you a while ago?
[01: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
[01:30] <indolering> Not in depth.
[01:31] <indolering> I think it runs but I've been stuck on a corrupted wallet issue.
[01:31] <@Jeremy_Rand> cassiniNMC: should I check on whether any of those machines is suitable for testing stuff for you?
[01:31] <+ryan-c> indolering: i still need someone to test my wallet recovery tools, sugarpuff is a flake
[01:32] <+ryan-c> indolering: if you wanna send me a wallet.dat i can try it myself
[01:32] <indolering> ryan-c: I can do that.
[01:32] <cassiniNMC> Jeremy_Rand: excellent, old CPUs with 10.9 Mavericks or 10.10 Yosemite is what we need for this test,
[01:33] <indolering> I have a backup, but neither the beta nor the previous QT build will open it.
[01:33] <indolering> They just crash on startup when I restore the .namecoin directory : (
[01: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)
[01:34] <@Jeremy_Rand> anything else cassiniNMC ?
[01:34] <cassiniNMC> indolering: did it start at all?
[01:34] <indolering> Splash screen then shut down.
[01:35] <cassiniNMC> as soon as we do the release 0.3.80 for Mac
[01:36] <cassiniNMC> I'm updating the wiki on How to Build Your Own Namecoin-Qt,
[01:36] <indolering> cassiniNMC: please
[01:37] <indolering> cassiniNMC: do you have privileges on the forum?
[01:37] <cassiniNMC> and if technically feasible I'll try to write an "easymacbuilder".
[01:37] <cassiniNMC> which privileges?
[01:37] <@Jeremy_Rand> cassiniNMC: with Namecore we will probably be using Gitian (so cross-compile everything from Linux)
[01:37] <indolering> Err, the wiki.
[01:37] <indolering> cassiniNMC: if you need any, just ask.
[01:38] <indolering> I think I made you an editor.
[01:38] <cassiniNMC> yes, I can write in the wiki.
[01:38] <indolering> Jeremy_Rand: yeah, we need to figure out an automated build system for Namecore.
[01:38] <indolering> And everything else.
[01:38] <cassiniNMC> ah, Gitian, I have to have a look into it.
[01:39] <@Jeremy_Rand> indolering: I expect the Gitian scripts from Bitcoin Core to work almost verbatim for Namecore
[01:39] <indolering> Or, rather, we need to figure out an automated build system and introduce it once we switch Namecore to the mainline branch.
[01:39] <@Jeremy_Rand> if they don't, then that would mean Daniel broke something
[01:39] <@Jeremy_Rand> right, I was talking to Daniel about automated builds
[01:40] <@Jeremy_Rand> I'm going to try both Travis CI and Drone.io
[01:40] <@Jeremy_Rand> Drone.io is probably adaptable to work with Gitian
[01:40] <@Jeremy_Rand> it uses Docker
[01:40] <mnp> travis is pretty nice
[01:40] <@Jeremy_Rand> and it's open source
[01:40] <indolering> Jeremy_Rand: I would suggest you, jbisch, or PMC work on setting a workflow for automated builds of Namecore.
[01:40] <+ryan-c> how much more did we want to cover? we're coming up on three hours.
[01:40] <@Jeremy_Rand> yeah, we've been here a while
[01:41] <@Jeremy_Rand> hl: anything else you want to cover?
[01: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.
[01: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.
[01:42] <@Jeremy_Rand> Yeah, I generally think that CA certs will cause a false sense of security among less technically competent users
[01: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.
[01: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)
[01: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?
[01: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.
[01:46] <+ryan-c> Jeremy_Rand: It's at least plausible that it would happen despite our protests.
[01: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
[01:47] <@Jeremy_Rand> Because if someone gets owned as a result,
[01:47] <@Jeremy_Rand> .bit will be blamed by some people
[01: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.
[01:48] <+ryan-c> Jeremy_Rand: encouraging users to trust a ca doesn't really matter anyway, nothing stopping a cert being issued right now.
[01:49] <+ryan-c> jbisch, hl, cassiniNMC, opinions?
[01:49] <@Jeremy_Rand> It's a worsening of the security offered by something based on Convergence or mitmproxy
[01:49] <@Jeremy_Rand> if a proxy is validating .bit, then no CA can subvert it
[01:50] <+ryan-c> Jeremy_Rand: even if CAs issue .bit certs a validating proxy prevents subversion.
[01:51] <@Jeremy_Rand> ryan-c: right, but if CA validation is available, fewer users will go through the trouble of installing a proxy
[01:51] <+ryan-c> Jeremy_Rand: It is less secure than a validating proxy, the question is whether it's better than nothing.
[01: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.
[01:51] <@Jeremy_Rand> Which would be harmful overall
[01:51] <indolering> Jeremy_Rand: community guidelines and the IETF spec are our only sources of leverage.
[01:52] <+ryan-c> Jeremy_Rand: We are comparing it to nothing at all.
[01:52] <indolering> IETF RFC*
[01:52] <indolering> Sorry, my internet connection dropped
[01: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.
[01: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
[01:53] <+ryan-c> Jeremy_Rand: I estimate that the first group is much larger than the second.
[01:53] <+ryan-c> Jeremy_Rand: if the first group is larger enough than the second, the tradeoff is a good one.
[01: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
[01:53] <+ryan-c> the question is what "larger enough" is.
[01:54] <@Jeremy_Rand> the proxies in existence suck
[01:54] <@Jeremy_Rand> making them better would improve adoption a lot
[01:54] == Guest42715 [~Sleepnbum@pool-108-13-12-95.lsanca.fios.verizon.net] has joined #namecoin-dev
[01:54] <@Jeremy_Rand> (and I say they suck despite being the maintainer of one)
[01:55] <+ryan-c> Jeremy_Rand: Security is not the only concern we should consider. Namecoin and .bit are pointless if nobody uses them.
[01: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.
[01:55] <@Jeremy_Rand> Nobody, would be pointless. Some number less than ubiquitous, would not necessarily be pointless
[01:55] <+ryan-c> I'm interested what other people think.
[01:56] <+ryan-c> jonasbits, midnightmagic, hl, cassiniNMC, JohnKenney are any of you here?
[01:57] <mnp> is there going to be an nmc application for key or certificate distribution ?
[01:57] <mnp> ie, stuff a cert in a c/somesite.bit name?
[01:57] <+ryan-c> mnp: we're supporting an analog of TLSA/DANE allowing ceritificate information to be included
[01:58] <indolering> Jeremy_Rand: any backwards compatible slution (JSDNS or a .bit suffix) needs a CA to sign off on their cert.
[01:58] <+ryan-c> mnp: it would be a fingerprint of the public key probably
[01:58] <jonasbits> ryan-c: I think you should go ahead and talk to the CA guys
[01: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.
|
