1 2015-09-09 00:53:41 <c55c50> da2ce7: what you really want is a friend to friend layer like retroshare, where peers create their own personal routes, encrypted and authenticated, and make their own decisions about ports and transports. it fixes denial of service, people doing wide scale monitoring of the network by connecting to every node, and sybil attacks. with no peer disco
  2 2015-09-09 00:53:41 <c55c50> very mechanism beyond human interaction you don’t expose the size of the network or  where it is located.
  3 2015-09-09 00:55:15 <da2ce7> c55c50, this is a possible approach;  however I was trying to get the lowest hanging fruit.  Imho, the lowest hanging fruit is in this order:
  4 2015-09-09 00:55:26 <da2ce7> 1.  Do DH + AES.
  5 2015-09-09 00:55:52 <da2ce7> 2. Pretend TLS, (that a dumb firewall cannot tell the difference).
  6 2015-09-09 00:56:20 <jamesob> hey phantomcircuit Luke-Jr, do you guys have any feelings about folding CLevelDBBatch into CLevelDBWrapper to avoid the ugly heap allocations in #6650?
  7 2015-09-09 00:56:24 <da2ce7> 3. Advanced TLS Masquerading; tor-like tls-lite.
  8 2015-09-09 00:58:07 <da2ce7> c55c50, if you want to have security, it should be by default, fast, and low cost.  People are lazy and won't go through any extra effort for security.
  9 2015-09-09 00:58:10 <phantomcircuit> jamesob, remember that you can have multiple outstanding batches in parallel
 10 2015-09-09 00:58:30 <c55c50> da2ce7: does doing encryption of public nodes traffic even matter though? if I want to monitor your node I just connect to it, if you're trying to hide the location of nodes it's ruined by the fact that   stuff like   http://getaddr.bitnodes.io/ provides an easy blocklist that you can download.
 11 2015-09-09 00:59:20 <da2ce7> c55c50, a massive amount.  What you are discribeing is the difference between a passive attacker and a active attacker.
 12 2015-09-09 00:59:27 <c55c50> I get the whole ENCRYPT EVERYTHING mantra but it doesn't seem to do much for a publicly peering network.
 13 2015-09-09 00:59:58 <da2ce7> especially for perfect forward secrecy. - it has a non-obvious security benefit to the average user.
 14 2015-09-09 01:00:23 <jamesob> phantomcircuit maybe the better option is to pass a CLevelDBWrapper reference into Batch's constructor and just reference obfuscate_key that way?
 15 2015-09-09 01:01:10 <da2ce7> in the general case, defending against active attackers is much much harder (and more expensive) than to defend against passive attackers.
 16 2015-09-09 01:01:40 <da2ce7> However this is contrasted that active attacks, in general, are more expensive to execute.
 17 2015-09-09 01:02:34 <c55c50> da2ce7: yeah but like, say the aim is to stop the network from being censored
 18 2015-09-09 01:03:29 <da2ce7> advanced TLS masquerading on port 443 would be harder to censor than retroshare.
 19 2015-09-09 01:04:21 <c55c50> da2ce7: http://pastebin.com/raw.php?i=6BxZFuK2
 20 2015-09-09 01:04:37 <c55c50> there's nothing active about that at all.
 21 2015-09-09 01:05:17 <da2ce7> getaddr.bitnodes.io is active.
 22 2015-09-09 01:08:18 <gmaxwell> da2ce7: I saw your comments last night and thought other people answered pretty well.  I don't think we want to go down the road of trying to make the plain p2p protocol censorship resistant. Tor already does this and has a lot more effort going into it. It's much harder than you think.
 23 2015-09-09 01:08:27 <c55c50> that is true, but the discovery mechanism means this is always possible for p2p no matter the transport.
 24 2015-09-09 01:08:41 <gmaxwell> da2ce7: If anything it would be better to just use tor for transport more, and contribute to making tor better.
 25 2015-09-09 01:09:26 <da2ce7> gmaxwell, then what about just plain DH + AES; basic FS?
 26 2015-09-09 01:09:45 <da2ce7> that would dramatically increase the cost / stop of passive observers .
 27 2015-09-09 01:10:15 <gmaxwell> an an aside, if you're worried about user privacy; the issues are elsewhere, something like 15 of the peers on my nodes are connected to _all_ my nodes, these are mostly spying nodes run by various and often unknown parties.  Transport confidentality isn't a concern when you can just be connected and instantly learn all you might want to learn.
 28 2015-09-09 01:11:46 <gmaxwell> da2ce7: that protects against passive observers who can monitor all your traffic (e.g. your ISP and sometimes some state actors)-- but the same parties can simply connect to you and learn all the same stuff! much easier and cheaper than tasking the big all seeing eye.  FS can be achieved also just by using tor for transport, which is generally a good idea.
 29 2015-09-09 01:12:14 <gmaxwell> I think if someone were to design a new p2p protocol, then sure, they'd make it more private... but as an upgrade to the existing one, I'd consider that a fairly low priority.
 30 2015-09-09 01:13:42 <da2ce7> hmm... attacks like: data-retention;  - going fishing in the past;  I suppose defending against those would have some benefit.
 31 2015-09-09 01:14:09 <gmaxwell> but as mentioned, there are many nodes that already connect to everything they can and, presumably, log everything.
 32 2015-09-09 01:14:34 <isis> zomg, i can't state strongly enough how much the "pretend we're 'normal' TLS" approach to censorship resistance has caused nightmare problems for us in Tor
 33 2015-09-09 01:15:01 <c55c50> isis: technically?
 34 2015-09-09 01:15:07 <gmaxwell> plus even with fs transport, you're completely transpartent to timing analysis. You send data over your bitcoin link and a transaction of the same size shows up at the same peers you just sent it to.
 35 2015-09-09 01:15:15 <isis> torspec §2 will give you a succinct taste of some of the headaches: https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt?id=a8f18f309b11854c58bf1d026dedcf8966a0f81e#n179
 36 2015-09-09 01:15:18 <petertod1> isis: examples?
 37 2015-09-09 01:15:43 <isis> it generally does not work out well at all, there is always a distinguisher
 38 2015-09-09 01:15:57 <petertodd> isis: what does work? (if anything)
 39 2015-09-09 01:16:02 <isis> which is why pluggable transports were invented
 40 2015-09-09 01:16:04 <gmaxwell> da2ce7: in bitcoin core, we've recently added an option to disable automatic transaction broadcast with the intention of supporting tx broadcast via a high latency mix network.
 41 2015-09-09 01:16:31 <petertodd> isis: ah, right, so pluggable transports themsleves are just as bad... but because pluggable not a maintenance headache?
 42 2015-09-09 01:16:34 <gmaxwell> da2ce7: thats a kind of direction that can really improve privacy, and also happens to not require "step 1. replace p2p protocol". :)
 43 2015-09-09 01:17:20 <da2ce7> isis, what we need to do is start a working committee for an extension for TLS that dose DH + AES FS *BEFORE* doing *ANYTHING* else.
 44 2015-09-09 01:17:25 <gmaxwell> Encryption is good, and should just be a default even where it isn't needed, but not carrying anything secret is even better. :)
 45 2015-09-09 01:17:35 <da2ce7> then hopefully get it rolled out to google.
 46 2015-09-09 01:17:38 <gmaxwell> da2ce7: you _stil_ end up with distinguishers.
 47 2015-09-09 01:17:46 <gmaxwell> da2ce7: also what you want there is called TCPCRYPT.
 48 2015-09-09 01:18:00 <gmaxwell> Which is currently slowly being killed in the IETF by advocates of TLS.
 49 2015-09-09 01:18:23 <petertodd> gmaxwell: well... make it clear that even if you aren't carrying anything secret, encrypted data is a public good because it improves others' k-anonymity sets (others could read that otherwise)
 50 2015-09-09 01:18:45 <isis> petertodd: yes, well… that's part of it (and a nice bonus too).  but more that the PTs have evolved to blend in in ways which "fuck it, just pretend we're Apache" could never do.
 51 2015-09-09 01:18:56 <gmaxwell> petertodd: it's good period, just good hygine, I agree. That said, the goal there is that no bitcoin p2p link carries anything secret.
 52 2015-09-09 01:19:31 <petertodd> gmaxwell: agreed - just maybe better to write that as "and in addition too" least newbies get the wrong impression
 53 2015-09-09 01:19:54 <da2ce7> gmaxwell: I suppose you would want to spend lots and lots of time to try an make the handshake before crypto as well-defined and as 'hairless' as possible. - once you have crypto, then you can go back to the mess of TLS.  - but maybe it is a fools game to go down that road.
 54 2015-09-09 01:20:08 <petertodd> gmaxwell: I've had the conversation "why should bitcoin p2p be encrypted?" before where people didn't know the public good aspect, and it often takes awhile to convince them of that
 55 2015-09-09 01:20:18 <petertodd> isis: PT's?
 56 2015-09-09 01:20:33 <petertodd> isis: oh, pluggable transports, right
 57 2015-09-09 01:20:36 <gmaxwell> da2ce7: no even if its indistinguishable that way, traffic analysis gives you away. Unless you want to suggest that all TLS be a constant bitrate 1mbit/sec stream. :P
 58 2015-09-09 01:20:36 <isis> petertodd: Pluggable Transports ←→ PTs
 59 2015-09-09 01:20:39 <c55c50> isis: hope that document is old, it's talking about 1024 bit RSA.
 60 2015-09-09 01:21:19 <da2ce7> gmaxwell, I suppose that's the 'there is no perfect security' road.
 61 2015-09-09 01:21:37 <petertodd> da2ce7: note how block propagation is (right now) a huge traffic analysis problem
 62 2015-09-09 01:21:39 <zooko> I'm hosting a workshop on Privacy and Scalability in Montreal this weekend.
 63 2015-09-09 01:22:30 <petertodd> oh! actually, come to think of it a possible attack re: "O(1)" block relaying protocols is you may have censors actively trying to do make traffic analysis work better by filling blocks up with data that hasn't been propagated before
 64 2015-09-09 01:22:40 <isis> c55c50: heh.  sadly it's not.  1024 RSA is correct, but then there's another layer of "circuit crypto" (curve25519, ed25519, and rsa1024) underneath
 65 2015-09-09 01:22:47 <gmaxwell> da2ce7: for bitcoin we have disjoint goals, we _must_ have strong partitioning resistance to avoid attacks on consensus... often things that improve privacy are bad for partitioning resistance. Fortunately privacy is only needed for transaction broadcasts (or that you're running bitcoin at all, which is something special)
 66 2015-09-09 01:22:59 <petertodd> zooko: cool! sorry, come to think of it I never replied to that email did I? :/
 67 2015-09-09 01:23:03 <zooko> If you have coherent analyses, empirical data, etc. on this topic please let me know, and come to that workshop.
 68 2015-09-09 01:23:14 <zooko> petertodd: oh, uh, yeah, you did. b
 69 2015-09-09 01:23:16 <zooko> ut ...
 70 2015-09-09 01:23:34 <isis> c55c50: that's just the "OR connection" layer, which uses OpenSSL TLS w/ PFS.
 71 2015-09-09 01:23:37 <petertodd> zooko: if I did, I probably said that basically all scalability tech inherently improves privacy
 72 2015-09-09 01:23:52 <zooko> That's a good point.
 73 2015-09-09 01:24:09 <petertodd> zooko: oh! did I tell you about how privacy and achiving strong partiitioning resistance go hand in hand? (ie to avoid DoS attacks)
 74 2015-09-09 01:24:13 <zooko> Yep, that's what you said. :-)
 75 2015-09-09 01:24:19 <da2ce7> I think that it can be separated in two parts:  transaction broadcasts need good anonymity; while everything else just needs censorship resistance.
 76 2015-09-09 01:24:37 <zooko> petertodd: the first thing is what you said -- about scalability tending to improve privacy.
 77 2015-09-09 01:24:43 <petertodd> zooko: would it help if I did a quick writeup of that on, say, the mailing list?
 78 2015-09-09 01:24:47 <zooko> The second thing, about active partitioning attacks, I don't think you've emailed me yet.
 79 2015-09-09 01:25:06 <zooko> petertodd: can you attend the Privacy workshop at SB/Montreal?
 80 2015-09-09 01:25:09 <gmaxwell> da2ce7: right, and the first we should be able to deliver almost perfectly with a high latency mix network.
 81 2015-09-09 01:25:26 <petertodd> zooko: I don't know what my schedule is - have they published it yet?
 82 2015-09-09 01:25:30 <zooko> gmaxwell, da2ce7: right, and in the nearer term we could deliver it pretty well by routing it over Tor.
 83 2015-09-09 01:25:35 <gmaxwell> (like mixmaster but bitcoin transactions only)
 84 2015-09-09 01:25:52 <gmaxwell> and yes, just using tor at all is a good start.
 85 2015-09-09 01:25:53 <zooko> petertodd: I'll ask jeremyrubin if he can spare you for that ...
 86 2015-09-09 01:25:56 <gmaxwell> though timing analysis is very powerful against bitcoin currently.
 87 2015-09-09 01:26:00 <petertodd> zooko: go for it
 88 2015-09-09 01:26:21 <petertodd> gmaxwell: note BTW that high latency tx mix networks make the "O(1)" block propagation story worse
 89 2015-09-09 01:27:17 <zooko> gmaxwell: that bit about timing analysis... would it apply if you just squirted transaction broadcasts over Tor, but nothing else?
 90 2015-09-09 01:27:26 <zooko> I ask because that's the approach we're thinking of for Zcoin.
 91 2015-09-09 01:27:33 <isis> mixmaster for bitcoin transactions would be awesome
 92 2015-09-09 01:27:49 <petertodd> zooko: the timing problem is mainly in block broadcasts, which are latency sensitive
 93 2015-09-09 01:28:01 <c55c50> zooko: someone running a bitcoin node just made a new tor circuit? they must be broadcasting a new transaction.
 94 2015-09-09 01:28:02 <zooko> isis: ☺
 95 2015-09-09 01:28:11 <zooko> c55c50: hm.
 96 2015-09-09 01:28:18 <petertodd> zooko: re: tx broadcasts, the solution is to hire some tor devs and make mix net happen, and increase the latency
 97 2015-09-09 01:28:33 <petertodd> zooko: speaking of, what kind of block interval are you thinking of?
 98 2015-09-09 01:28:45 <zooko> petertodd: our rule is to ape Bitcoin
 99 2015-09-09 01:28:51 <gmaxwell> zooko: yes, at least with repeated transactions the timing signal is very clear.
100 2015-09-09 01:29:04 <petertodd> zooko: some analysis of block interval vs. timing analysis could be interesting, though I worry that it'd lead people to lean towards shorter intervals dangerously...
101 2015-09-09 01:29:27 <zooko> petertodd: why does the block interval matter?
102 2015-09-09 01:29:44 <zooko> The eavesdropper is presumably also listening to broadcasts of new transactions through the p2p network?
103 2015-09-09 01:29:46 <petertodd> zooko: to which thing? timing analysis or blocks?
104 2015-09-09 01:29:58 <zooko> timing vs. privacy
105 2015-09-09 01:30:29 <zooko> gmaxwell: did you know that I worked on MixMinion, back in the paleolithic era?
106 2015-09-09 01:30:37 <midnightmagic> I knew!
107 2015-09-09 01:30:52 <petertodd> zooko: re: timing analysis, specifically determining *if* a network connection is running a *coin node, there may be a tradeoff in that longer (or shorter!) block intervals give better statistical information to the attacker - I don't know!
108 2015-09-09 01:31:20 <midnightmagic> :-)
109 2015-09-09 01:31:25 <phantomcircuit> jamesob, not sure
110 2015-09-09 01:31:33 <petertodd> zooko: e.g, imagine if the block interval was one year - you could spread a block transmission out over a while day to defeat timing analysis with little effect on miner profitability
111 2015-09-09 01:31:45 <phantomcircuit> i get the feeling that a virtual interface for k/v database access might be useful
112 2015-09-09 01:32:23 <zooko> petertodd: wait, this is to hide whether a given Tor circuit is being used for a miner vs. to browse nytimes.com ?
113 2015-09-09 01:32:25 <jamesob> what would that buy us?
114 2015-09-09 01:33:09 <jamesob> phantomcircuit ^
115 2015-09-09 01:33:10 <zooko> I'm supposed to lead this privacy workshop, but I really need someone to explain to me what the basic principles are in terms of what at least arguably matters.
116 2015-09-09 01:33:19 <petertodd> zooko: yes, though I'd further say that you really want all nodes to be sufficiently low latency to act like miners (which is maybe unclear if you don't know my arguments on privacy and DoS attack resistance)
117 2015-09-09 01:33:25 <zooko> Is running a miner without letting your enemies know that you're doing so important and/or possible?
118 2015-09-09 01:33:48 <petertodd> zooko: for determining tx source information, where you don't care about who is or isn't running a node, a tx mixnet seems obviously like it'll work
119 2015-09-09 01:34:12 <zooko> petertodd: yeah, this idea of a high-latency tx mixnet is a pretty attractive idea.
120 2015-09-09 01:34:45 <petertodd> zooko: OTOH there's a danger in that latency may give reasons to actively defeat that mixnet to earn more money, depending on the shape of the fee/KB curve in the tx backlog at any one time. (e.g. suppose the curve was very steep, so learning about a tx later than another miner meant on average your fee/KB was lower)
121 2015-09-09 01:34:53 <c55c50> zooko: I don't think so, 1% of the bitcoin p2p network also have a stratum port open.
122 2015-09-09 01:36:07 <zooko> c55c50: what's the significance of that?
123 2015-09-09 01:36:39 <c55c50> zooko: miners don't care about hiding?
124 2015-09-09 01:36:53 <petertodd> zooko: hypothetical example: if someone broadcasts a 100BTC fee tx, every second it takes for you to learn about that tx is costing you 100BTC * 25BTC/600s * q expected income
125 2015-09-09 01:38:02 <zooko> c55c50: you mean 1% of them don't? Or do you mean something else?
126 2015-09-09 01:38:32 <zooko> petertodd: okay, but the miners having a selfish interest in learning about txes doesn't prevent a high-latency mix network.
127 2015-09-09 01:38:50 <c55c50> zooko: of the 5500 nodes with open 8333, around 90 have their mining port exposed too.
128 2015-09-09 01:38:50 <petertodd> zooko: er, wait, no, 100BTC/600s * q expected income...
129 2015-09-09 01:39:07 <zooko> Unfortunately, I have to leave now. Thanks for the discussion, folks!
130 2015-09-09 01:39:10 <petertodd> zooko: it could! if it means they're attacking the high-latency mix network!
131 2015-09-09 01:39:25 <zooko> petertodd: Oh, actively attacking, you mean, in order to delay their competitors learning about the tx.
132 2015-09-09 01:39:37 <petertodd> zooko: that's actually a decent argument for making tx fees apply to more than just one block, e.g. 1/2 in block 0, 1/4 in block 1, etc.
133 2015-09-09 01:39:43 <petertodd> zooko: exactly
134 2015-09-09 01:39:46 <zooko> petertodd: Hm.
135 2015-09-09 01:39:47 <petertodd> zooko: or sybil attacking
136 2015-09-09 01:39:49 <zooko> Okay, gotta run.
137 2015-09-09 01:39:52 <petertodd> zooko: later!
138 2015-09-09 01:41:20 <asn> hi. started lurking late. is there some background reading i can do to get more accustomed with this discussion?
139 2015-09-09 01:41:36 <asn> i mean bitcoin + tor / high latency mix network
140 2015-09-09 01:41:40 <petertodd> asn: as in the terminology/concepts being used?
141 2015-09-09 01:42:10 <asn> yeah, tryign to grasp the threat model. or even how this is going work at all. i joined 5 minutes ago literally.
142 2015-09-09 01:42:29 <gmaxwell> zooko: one hop transaction timing privitizing in bitcoin has a really nice property that it's inherently dos attack resistant: all inputs have to be valid txn.  Sadly that breaks if extending to multiple hops. :(
143 2015-09-09 01:42:31 <asn> is there like a proposal or somethig that is being discussed?
144 2015-09-09 01:42:47 <petertodd> asn: nah, just ideas at this point, nothing concrete
145 2015-09-09 01:42:53 <asn> ack
146 2015-09-09 01:43:07 <petertodd> asn: btw this channel is logged, so you can easily get backlogs
147 2015-09-09 01:43:18 <asn> helpful. thanks!
148 2015-09-09 01:43:39 <gmaxwell> asn: It's been discussed quite a few times, but it's scattered. There are many privacy issues in bitcoin some are harder to solve than others.  One of them-- monitoring transaction origins is encouraging abusive network behavior (people sybil attacking to monitor users)
149 2015-09-09 01:44:03 <gmaxwell> This elevates the importance of doing something about it, beyond the base privacy concerns.
150 2015-09-09 01:44:36 <asn> what are the attackers sybiling as?
151 2015-09-09 01:44:59 <asn> is this about building some sort of bitcoinfog thing into bitcoin?
152 2015-09-09 01:45:06 <gmaxwell> asn: pretending to be ordinary nodes in order to try to get direct connections to every wallet.
153 2015-09-09 01:45:09 <asn> or something like the zerocoin thing?
154 2015-09-09 01:45:10 <gmaxwell> No.
155 2015-09-09 01:45:11 <asn> i mean in result.
156 2015-09-09 01:45:13 <petertodd> gmaxwell: re: tx origins, might be an idea to make new txs have staggered inv behavior, e.g. only broadcast to somewhere between one or two peers initially
157 2015-09-09 01:45:24 <asn> gmaxwell: oh.
158 2015-09-09 01:45:44 <gmaxwell> In the last release of bitcoin core we added a setting to disable the local broadcast of transactions. This means you can run a daemon alongside your wallet that periodically grabs your transactions and and handles getting them to the network in a way which doesn't make it interesting for attackers to sybil attack to trace transaction origins.
159 2015-09-09 01:45:47 <asn> gmaxwell: and after they get direct connection to a wallet, what can the attacker do?
160 2015-09-09 01:45:59 <gmaxwell> Even if Bitcoin had cryptographic privacy this kind of connect and watch vulnerability exists.
161 2015-09-09 01:46:26 <gmaxwell> asn: they use it to figure out which transactions that wallet originated, then correlate that with other information they know about the address and sell the result-- or some of them do, god knows what the rest do.
162 2015-09-09 01:46:42 <asn> i see. i was not familiar with this nasty attack vector.
163 2015-09-09 01:47:04 <asn> ok. so some anonymity for entering the bitcoin network would be helpful i guess
164 2015-09-09 01:47:12 <asn> to make it harder to trace back to specific wallet IPs.
165 2015-09-09 01:47:14 <gmaxwell> In particular just for getting transactions into it.
166 2015-09-09 01:47:17 <asn> right
167 2015-09-09 01:47:24 <gmaxwell> And thats a pretty easy problem.
168 2015-09-09 01:47:33 <asn> yeah SOCKS client and tor whatever. i guess.
169 2015-09-09 01:47:49 <gmaxwell> no consensus, not a large amount of data. No super high delay requirements.
170 2015-09-09 01:48:04 <asn> ok
171 2015-09-09 01:48:19 <asn> so where does it go wrong?
172 2015-09-09 01:48:49 <gmaxwell> hm. doesn't just not implemented yet. It's an easy win.
173 2015-09-09 01:48:57 <isis> i think i've understood more just now what petertodd was trying to explain to zooko: if miners are incentivised to want to recieve new TXs sooner, then they are disincentivised to hold on to mixminion-y TXs for the desired batching period
174 2015-09-09 01:49:05 <isis> makes more sense now
175 2015-09-09 01:49:18 <isis> petertodd: is that what you meant? ↑
176 2015-09-09 01:49:26 <petertodd> isis: yes!
177 2015-09-09 01:49:29 <gmaxwell> isis: yes, though we can nlocktime transactions to remove that concern, if its an issue.
178 2015-09-09 01:49:39 <isis> because there is a simple fix to that problem
179 2015-09-09 01:49:55 <petertodd> isis: but even worse: miners may actively sybil attack the mixnet to be more likely to see such txs
180 2015-09-09 01:50:05 <petertodd> isis: and yeah, greg's right that nLockTime can help here
181 2015-09-09 01:50:20 <gmaxwell> (makes it impossible to include the transactions in blocks until the network time advances to the nlocked time)
182 2015-09-09 01:50:25 <isis> gmaxewll: right!  just wrap each layer of the mixminion-y crypto with a TX fee thing that becomes valid later, encouraging them to wait
183 2015-09-09 01:50:43 <asn> gmaxwell: so if it's so easy. where does this miner & mixnet madness come in?
184 2015-09-09 01:50:44 <petertodd> isis: well, the tx itself is simply invalid to put into a block until later
185 2015-09-09 01:50:58 <gmaxwell> petertodd: well a point there is that most of my motivation here is not privacy (just because there are so many other privacy problems) but just to discourage the abusive behavior.
186 2015-09-09 01:51:19 <petertodd> gmaxwell: which is a problem, because even with my nLockTime patch, users are creating txs that are minable right now
187 2015-09-09 01:51:32 <da2ce7> gmaxwell: on another privacy note,  what about the idea to use single-key p2sh addresses by default for bitcoin core?  So the output scripts are hidden until spend?  Is this worthwhile?
188 2015-09-09 01:51:34 <asn> and why do we want high latency? isn't tor sufficient?
189 2015-09-09 01:51:34 <petertodd> gmaxwell: we need users to create txs that are minable in the future for it to help re: mixnets for all txs
190 2015-09-09 01:51:57 <asn> the monitoring attacker won't be able to trace the transaction to a specific IP. why do we care about high latency and mixnets?
191 2015-09-09 01:51:57 <petertodd> gmaxwell: the sybil attackers have explicit goals of learning all tx origins, not just some tx origins (this is KYC snakeoil being sold to banks remember)
192 2015-09-09 01:52:17 <gmaxwell> asn: because there is a trivial timing attack that can be easily removed in this application, so why not? e.g. without solving that the bad behavior is just pushed back another layer perhaps.
193 2015-09-09 01:52:57 <asn> gmaxwell: hm. what is the trivial timing attack?
194 2015-09-09 01:53:13 <gmaxwell> asn: already users can just use tor (tm) and we encourage it, but the attackers still exist. :P irritatingly users get easily talked into dismissing modest security improvements, stronger ones can help.
195 2015-09-09 01:53:15 <asn> monitoring attacker sees transaction from exit node. and matches it with client connection to entry guard?
196 2015-09-09 01:53:26 <asn> attacker needs to get client's IP right? or what?
197 2015-09-09 01:53:49 <asn> (fwiw, i'm not trying to push for tor that much. just trying to understand the reality of the problem.)
198 2015-09-09 01:54:07 <gmaxwell> asn: well I'd assume anything here would run over tor in any case.
199 2015-09-09 01:54:24 <asn> i mean, tbh, bitcoin using a mixnet would be epic. so much cover traffic.
200 2015-09-09 01:54:30 <asn> or are we talking about bitcoin becoming a mixnet?
201 2015-09-09 01:54:37 <petertodd> isis: is there an analogous problem in Tor re: "learning the origin of a flood fill"? sounds like the kind of thing that might have some reasearch already on it... I'm especially interested if my suggestion of limiting how many peers you advertise new messages to at once could help
202 2015-09-09 01:55:09 <gmaxwell> asn: even the simple one hop version would be a big improvment ... thats where the client submits transactions just by connecting to a HS, sending a constant amount of data, HS batches for a brief window, transmits to a random bitcoin node.
203 2015-09-09 01:55:49 <asn> and this for all transactions of the network?
204 2015-09-09 01:55:55 <asn> fun :)
205 2015-09-09 01:56:07 <asn> is that lots of bandwidth? maybe not that much.
206 2015-09-09 01:56:22 <gmaxwell> Ideally. Presumably we'll find that there are some less privacy friendly wallet vendors that wouldn't use it.
207 2015-09-09 01:56:30 <gmaxwell> No, it's not much bandwidth.
208 2015-09-09 01:56:44 <asn> and who would run those HSes or mixnet nodes?
209 2015-09-09 01:56:50 <asn> or you have not gone that far in thinking
210 2015-09-09 01:56:54 <gmaxwell> No freeking idea.
211 2015-09-09 01:56:58 <asn> ok
212 2015-09-09 01:57:36 <isis> asn: there was a brief discussion in the scrollback about "mimicking TLS" to try to provide censorship resistance, which i tried to summarise the horrors Tor has experienced with that approach, and that it was part of the reason you invented PTs, and that perhaps if bitcoin wants censorship resistance that they should use PTs. (that discussion somehow turned into this mixminion-for-bitcoin one)
213 2015-09-09 01:57:37 <asn> an evil miner who runs mixnet nodes has advantage if he can selectively delay transactions?
214 2015-09-09 01:58:21 <isis> but he is disincentivised from doing so
215 2015-09-09 01:58:25 <asn> and all this stuff, for an attacker who matches some transactions to client IPs.
216 2015-09-09 01:58:40 <asn> what % of total transsactions can a realistic attacker monitor?
217 2015-09-09 01:58:47 <petertodd> asn: in general, remember that for mining if you're competition doesn't know about a block, they're not earning money and you are; with optimized relay protocols not learning about transactions is analogous to not learning about blocks
218 2015-09-09 01:58:55 <asn> like have clients connect directly to him.
219 2015-09-09 01:59:28 <gmaxwell> asn: almost all of them? there aren't _that_ many bitcoin nodes. :( And generally our design is for partition resistance, the exact opposite topology for privacy, bitcoin nodes are highly promiscious.
220 2015-09-09 01:59:32 <petertodd> isis: note that in mining, you are disincentivised from your blocks reaching <30% of hashing power, but past that point additional hashing power your blocks reach helps your competitiors more than it helps you
221 2015-09-09 01:59:55 <gmaxwell> e.g. normal bitcoin core nodes connect out to 8, in from as much as 125 and tell everyone everything they know.
222 2015-09-09 01:59:59 <asn> ouch.
223 2015-09-09 02:00:09 <asn> or maybe not that ouhc.
224 2015-09-09 02:00:11 <isis> petertodd: ah, interesting…
225 2015-09-09 02:00:29 <asn> fwiw, have people done statistics on what IPs connect to those nodes? like how many people use tor or whatever?
226 2015-09-09 02:00:33 <c55c50> asn: making 6000 TCP connections is trivial.
227 2015-09-09 02:00:44 <gmaxwell> which is what the consensus protocol needs, ... you need at least one honest peer to not be partitioned... but privacy wants something more like no dishonest peers, the compliment.
228 2015-09-09 02:01:27 <asn> 01:56 < gmaxwell> No, it's not much bandwidth.
229 2015-09-09 02:01:39 <petertodd> now, do remember that from a network-wide point of view, simultaneoulsy broadcasting information to all peers at once isn't ideal - you should be spending your resources getting information to a small subset as fast as possible, so that exponential growth can happen faster. That subset effect makes it harder - but not impossible - sybil attack the network to learn origin information.
230 2015-09-09 02:01:40 <asn> possibly more banidwdth than any currently alive mixnet can survive though.
231 2015-09-09 02:01:58 <petertodd> asn: that's basically saying all current mixnets are crap :)
232 2015-09-09 02:02:01 <gmaxwell> asn: there is a small but non-trivial fraction of tor users. I don't have current numbers, probably figure a couple percent.
233 2015-09-09 02:02:22 <asn> petertodd: i think they are just not used a lot.
234 2015-09-09 02:02:36 <asn> petertodd: well if btc started using them they would become much more fun.
235 2015-09-09 02:02:39 <isis> petertodd: (re: "learning the origin of a flood fill") i… don't think we've experienced anything directly like that in tor.  hidden service guard discovery might be the closest thing.
236 2015-09-09 02:02:50 <gmaxwell> asn: bitcoin is currently by design limited to a long term average of about 14kbit/s. So really not that much.
237 2015-09-09 02:02:58 <asn> gmaxwell: oh ok. so most people connect bareback. nasty.
238 2015-09-09 02:02:58 <petertodd> asn: they aren't used much agreed - setting up one that can handle bitcoin isn't hard though
239 2015-09-09 02:03:44 <xtalmath> the difficulty is based on the time elapsed after some number of blocks correct?
240 2015-09-09 02:03:48 <gmaxwell> asn: well we have some potential advantages, if the system is only handling bitcoin transactions it benefits from the inherent flodding attack resistance we have for bitcoin transactions.
241 2015-09-09 02:04:11 <gmaxwell> xtalmath: ratio of two weeks to the difference of ntimes across an interval of 2016 blocks
242 2015-09-09 02:04:32 <asn> i have no idea what is inherent flodding attack resistance and why would that be helpful for a mixnet.
243 2015-09-09 02:04:34 <c55c50> asn: the software by default uses upnp to make a "bareback" TCP socket and advertises it for other people to use.
244 2015-09-09 02:05:18 <asn> the other question is, would the mixnet operators be able to read the transactions that are getting carried.
245 2015-09-09 02:05:20 <petertodd> asn: we have a handy transferrable PoW system to limit attacks by making them expensive :)
246 2015-09-09 02:05:27 <isis> petertodd: or maybe a closer analogue would be hidden service descriptor discovery, e.g. by generating identity keys such that (with the current HS design, but not the new one) you sit in a place in the hashring that people would ask you for a some HS
247 2015-09-09 02:05:36 <asn> probably the "exit node" would have that ability. except if it's somehow end to end (???).
248 2015-09-09 02:05:37 <xtalmath> ignoring the unlogical case, but consider hypothetically that the hashing power on the network halves for a sustained period, will the difficulty become easier, or is it hardcoded to only increase monotonically?
249 2015-09-09 02:05:52 <gmaxwell> asn: it's okay if the end does in any case, since it's going to end up on the public network.
250 2015-09-09 02:06:00 <gmaxwell> asn: middle.. more complicated.
251 2015-09-09 02:06:03 <isis> petertodd: but still none of those really have the topological component
252 2015-09-09 02:06:11 <petertodd> xtalmath: easier - difficulty isn't hardcoded in any way
253 2015-09-09 02:06:16 <asn> but you were discussing that the end can then delay it, if it's also a miner. and then she gets money or something.
254 2015-09-09 02:06:29 <gmaxwell> If data is constrained to be a valid bitcoin transaction an attack cannot cheaply exhaust capacity. But without going into ZKP fantasy land that means cleartext.
255 2015-09-09 02:06:30 <petertodd> isis: hmm, too bad, maybe I'll try the academic literature then
256 2015-09-09 02:07:15 <asn> so the crazy miner attack here is
257 2015-09-09 02:07:24 <gmaxwell> asn: PT commented on that, I don't consider it much of a concern, if the transaction doesn't show up on the network in the expected time, you can resend to another exit.
258 2015-09-09 02:07:26 <petertodd> isis: I know a fair bit of work has been done on propagation in general on random graphs
259 2015-09-09 02:07:41 <asn> "I'm a miner, and i'm also a mixnet/tor exit node. I see all the transactions flowing through me. I pick the ones with high transaction fee and keep them only for myself till I find a block."?
260 2015-09-09 02:07:58 <gmaxwell> it's not an interesting attack in today's bitcoin network, that miners would bother delaying broadcasting a transaction in order to get exclusive dibs on a couple cents fee. :)
261 2015-09-09 02:08:06 <gmaxwell> asn: yes, exactly.
262 2015-09-09 02:08:08 <xtalmath> so suppose someone somehow breaks the cryptographic hash, and mines the rest of the coins at once, then this person could also mine some remaining blocks to lower the difficulty back so the miners can continue as he retreats into the dark?
263 2015-09-09 02:08:15 <asn> but they also have to get the block.
264 2015-09-09 02:08:31 <asn> otherwise, they delay for nothing. i guess they don't care.
265 2015-09-09 02:08:59 <asn> maybe they should not be able to delay without forwarding. somehow. proof of tx delivery?
266 2015-09-09 02:09:00 <gmaxwell> asn: in that model they'd just sit on it until they did, unless the user resent to another exit they'd eventually get it.
267 2015-09-09 02:09:08 <petertodd> xtalmath: if SHA256 is broken to that extent, chances are coins can be just stolen directly - the security needed for PoW to work is significantly less than almost any other use of hash functions (even MD5 is fine)
268 2015-09-09 02:09:42 <asn> why don't clients broadcast their tx to like 20 nodes. and then they can't all delay it.
269 2015-09-09 02:09:50 <xtalmath> petertodd: suppose the attacker does not want to piss people off or commit a crime (as he may or may not be caught later on)
270 2015-09-09 02:10:22 <gmaxwell> asn: or that. thats a little less private. in the sense that now an attacker with one exit now can reliably distinguish the anonymity set of users using this system vs not.
271 2015-09-09 02:11:07 <asn> which system you mean?
272 2015-09-09 02:12:33 <asn> not sure what you were referring to lol
273 2015-09-09 02:12:42 <xtalmath> *he/she
274 2015-09-09 02:13:24 <midnightmagic> The tor exit node can corelate bitcoin identities more quickly/reliably because the chances they see more of the tx of people using the tor rebroadcast mechanism, are higher
275 2015-09-09 02:13:36 <asn> ah
276 2015-09-09 02:13:54 <asn> but what is the exit going to corellate it with? they don't know the IP of that filed the tx.
277 2015-09-09 02:14:09 <asn> what else is there apart from the IP that we are trying to protect?
278 2015-09-09 02:14:30 <midnightmagic> identities in bitcoin, it turns out, are very easy to correlate with transactions.
279 2015-09-09 02:15:07 <asn> is there some identifying info in the transaction message, that does not get published on the blockchain?
280 2015-09-09 02:15:20 <asn> that we are trying to protect?
281 2015-09-09 02:16:15 <midnightmagic> .. just the fact that they are using the tor exit node, I'm assuming.
282 2015-09-09 02:16:58 <asn> that doesn't seem very exciting to me.
283 2015-09-09 02:17:07 <asn> especially if we assume that the whole network will switch to tor (or to mixnets)
284 2015-09-09 02:17:22 <asn> because that's what we are discussing here iiuc
285 2015-09-09 02:17:24 <gmaxwell> bad assumption.
286 2015-09-09 02:17:39 <asn> ah
287 2015-09-09 02:17:58 <asn> well in that case, it's still better than now.
288 2015-09-09 02:18:13 <gmaxwell> There will be users who don't switch, e.g. because the authors of their software are MIA (or are actively opposted to anything that improves privacy),  it's somewhat preverable to unify the anonymity sets if possible. :)
289 2015-09-09 02:18:17 <gmaxwell> But yes.
290 2015-09-09 02:18:52 <gmaxwell> As I said, I think the delay thing is not terribly interesting as an attack currently. People could sybil attack the bitcoin network to try to do that already, but AFAICT thats never been done.
291 2015-09-09 02:19:13 <asn> doesn't sound very profitable currently.
292 2015-09-09 02:19:53 <asn> so it seems that this discussion is leading to retaining status quo
293 2015-09-09 02:20:12 <asn> that is, some people can use anonymizing tools. and those people won't get busted by the crawling fuckers.
294 2015-09-09 02:20:22 <asn> other people won't use it. and those people will get archived. but maybe they don't care.
295 2015-09-09 02:20:25 <asn> and everyone is happy?
296 2015-09-09 02:21:16 <asn> if you want mandatory protection from all people (and greater anonymity set for the weak), you would have to enforce it somehow.
297 2015-09-09 02:21:29 <asn> either by including it by default in the main wallets.
298 2015-09-09 02:21:54 <asn> or by asking miners to only consider anonymized messages (who would probably not follow your advice because why the fuck).
299 2015-09-09 02:21:59 <xtalmath> petertodd: could such an attacker (who instantaneously emits a series of blocks to mine all remaining btc) emit a series of blocks such that the error in time in his last block is arbitrarily small?
300 2015-09-09 02:29:07 <gmaxwell> asn: thats why you want the privacy tools so also protect the non-users.
301 2015-09-09 02:29:30 <gmaxwell> certantly it can be a default in privacy conscious software, but no one controls everything.
302 2015-09-09 02:31:07 <asn> you could turn the btc network into some sort of crazy mixnet
303 2015-09-09 02:31:25 <asn> in a way that forces clients to use it if they want their tx to reach the miners
304 2015-09-09 02:31:44 <asn> or maybe you could not do that, because someone will fork. i have no idea about the btc social dynamics.
305 2015-09-09 02:41:18 <gmaxwell> asn: there are many wallet implementations already. some already just funnel all their txn through some centeralized servers that monitor them, etc.
306 2015-09-09 02:41:42 <dcousens> gmaxwell: that [may/could] monitor them
307 2015-09-09 02:41:55 <dcousens> Centralization doesn't always equate to evil,  it just allows it
308 2015-09-09 02:42:03 <gmaxwell> no no I mean I know some do!
309 2015-09-09 02:42:31 <gmaxwell> certantly presumably do not! :)
310 2015-09-09 02:42:49 <gmaxwell> and I don't mean to suggest thats worse, better to have one party monitor you than anyone who wants to.
311 2015-09-09 02:42:58 <dcousens> gmaxwell: indeed :)
312 2015-09-09 02:43:46 <dcousens> gmaxwell: infact, I know I moved away from SPV because I can trust a centralized service whom the operators I know (and help) much more than I can trust compared to sending a all-telling bloom filter to every tom dick and harry on the bitcoin network
313 2015-09-09 02:44:48 <gmaxwell> Agreed.
314 2015-09-09 02:45:58 <dcousens> Personally, the only reason I want to use a bloom filter now, is to reduce some of my query sizes :)
315 2015-09-09 02:46:41 <dcousens> But their may be better ways to do that anyway
316 2015-09-09 03:00:09 <jamesob> anyone ever have PR builds timeout on rpc tests? is reproducing locally as simple as ./qa/pull-tester/rpc-tests.sh?
317 2015-09-09 03:00:13 <jamesob> e.g. https://travis-ci.org/bitcoin/bitcoin/jobs/79222231
318 2015-09-09 03:18:23 <Luke-Jr> jamesob: at least running the RPC tests individually should work
319 2015-09-09 03:57:20 <jamesob> Thanks Luke-Jr; eventually got it by handhacking in `-printtoconsole` to test_framework
320 2015-09-09 03:58:17 <jamesob> might file a pr making that easier...
321 2015-09-09 06:26:45 <jonasschnelli> jamesob: no need to add -printtoconsole to test_framework: just "tail -f" the nodes debug.log?
322 2015-09-09 16:58:46 <bedeho> 1) is the dust limit rule a consensus rule, or just a relay policy? 2) If a tx spends a dust quantity to fees, and has no outputs, does it also violate this or any other rule?
323 2015-09-09 17:09:39 <paveljanik> bedeho, do you see any dust transactions in the blockchain? ;-)
324 2015-09-09 17:11:53 <paveljanik> so the answer to your question is: relay policy.
325 2015-09-09 17:12:17 <bedeho> paveljanik, ok,ty, and how about 2) ?
326 2015-09-09 17:13:08 <paveljanik> bedeho mmnt :-)
327 2015-09-09 17:13:09 <paveljanik> if (tx.vout.empty())
328 2015-09-09 17:13:09 <paveljanik> return state.DoS(10, false, REJECT_INVALID, "bad-txns-vout-empty");
329 2015-09-09 17:13:25 <paveljanik> so such transaction is invalid.
330 2015-09-09 17:13:40 <paveljanik> no outputs -> invalid transaction
331 2015-09-09 17:13:57 <bedeho> wow, really? I was told before that they were valid
332 2015-09-09 17:14:13 <bedeho> but is that also just relay policy?
333 2015-09-09 17:14:28 <paveljanik> It can have a zero value output though (e.g. OP_RETURN).
334 2015-09-09 17:15:08 <bedeho> ah interesting, ok, this is saying the same thing http://bitcoin.stackexchange.com/questions/12451/are-bitcoin-transactions-permitted-to-have-no-outputs-i-e-all-inputs-become-tr
335 2015-09-09 17:15:17 <bedeho> apparently this is also just rely policy
336 2015-09-09 17:15:49 <paveljanik> this is part of CheckBlock, so even a block with such transaction will be invalid.
337 2015-09-09 17:16:25 <bedeho> ok, interesting, thank you!
338 2015-09-09 17:33:23 <nwilcox> Is there a concise history of DoS vulnerabilities and their mitigations throughout core's evolution?
339 2015-09-09 17:33:57 <nwilcox> I don't understand all of the trade-off decisions which have been made.
340 2015-09-09 17:34:37 <nwilcox> eg: I don't know at first thought, any reason not to allow 0-txo transactions. In fact, they relieve UTXO pressure, right?
341 2015-09-09 17:49:27 <bedeho> nwilcox, such history would be a great read, e.g. the dust limit seems a bit like a fudge, so must have been a serious problem at one point.
342 2015-09-09 17:53:15 <arubi> I'd love to know the reason as well. it seems a tx with no outputs, and with a reasonably expensive input might create an incentive for miners to try to orphan an existing top block cointaining it in order to get the fees for themselves. this could be used to dos the network by investing, say 150 btc and have miners forcefully trying to fork the best chain for some time period.
343 2015-09-09 17:56:13 <bedeho> arubi, if that was really a serious problem, than it would apply equally to the presence of any high fee tx, with or without outputs. Very sceptical that that attack would make economic sense.
344 2015-09-09 17:56:18 <kadoban> arubi: That's not prevented now. You can have arbitrarily high txfee in a transaction. I also suspect that's not a real feasible attack.
345 2015-09-09 17:59:14 <arubi> yea, you're both right. I didn't consider just making a normal transaction with a high enough fee..
346 2015-09-09 18:02:29 <kadoban> It would be kinda interesting to see what would happen ... but I suspect in practice miners probably aren't watching for that, so it'd just be boring and nothing would happen.
347 2015-09-09 18:03:35 <arubi> yea I was just going to ask if you think it's not feasible because miners are not consciously checking for this scenario
348 2015-09-09 18:05:29 <kadoban> Even if they were ... I'm still not sure if it'd actually cause any big problem. It could, maybe? Would have to do some game theory analysis or something that's beyond me at the moment.
349 2015-09-09 18:11:51 <bedeho> arubi, the fact that they are nto checking is not the problem - that is the symptom, they are not checking because it is almost certainly not profitable to try to do. Monitoring is easy, and they likely do collect all sorts of data on transaction types to optimize they block building routines. Even if there was lots of fees associated with such txs, which there arent, then the total hashing power would reflect this (e.g.
350 2015-09-09 18:11:52 <bedeho> imagine what would happen to hash supply if there were millions/day in fees), so forking the chain to steal fees would be no more profitable in this scenario than under regular conditions.
351 2015-09-09 18:12:11 <bedeho> which means it wouldnt be unless you have some very significant proportion of hashing power
352 2015-09-09 18:12:43 <kadoban> It'd be funny if it were something like ... the right move is to mine a block without that tx, because otherwise everyone has too much of an incentive to ignore your block. So the tx just never confirms XD
353 2015-09-09 18:12:44 <bedeho> alternatively, there are a bunch of free lunches lying around for you if you are the only person who botheres to check for these huge fees... but that will not be the case in equilibrium
354 2015-09-09 18:18:06 <arubi> bedeho, there were times where certain pools were well above 30% of the hashrate right? it might be profitable for such a large pool to try and orphan some blocks in order to steal the fees (I think..).   kadoban, I think you're right.
355 2015-09-09 18:21:09 <arubi> if you did want to mine that tx, you'd probably try to mine a secret chain of a few blocks so the mined tx is well beneath the head, but if no one ever mines it and blocks are coming in as usual, then you'll have to start mining the secret chain from the head block every time instead of just adding to it if the tx _was_ mined in a block
356 2015-09-09 18:22:35 <arubi> "usual" means whatever hashrate is left on the network if your own is dedicated to mine that specific tx
357 2015-09-09 18:24:37 <kadoban> I think it's only interesting if just about all of the hashpower is making the same calculation, or if you have a really big slice of the hashpower, yeah. Otherwise it gets boring again and first will win.
358 2015-09-09 20:10:34 <ui> hello, I'm trying to install multibit on Ubuntu 15.04 then first off, when i dl the file from the multibit homepage, the file is not a jar file but .sh second when i do try to open it with java it gives me an error message Error: Invalid or corrupt jarfile /home/r/Downloads/multibit-hd-unix-0.1.3.sh
359 2015-09-09 20:11:00 <ui> anyone tried something similar or can give some help, been looking around quite a bit
360 2015-09-09 20:12:56 <pigeons> ui: let's take this to #bitcoin or somewhere else, but run the .sh file via sh or bash not java: bash /home/r/Downloads/multibit-hd-unix-0.1.3.sh
361 2015-09-09 20:19:21 <ui> thanks. thought it might be technical issue though.
362 2015-09-09 20:20:17 <ui> and it works