1 2016-10-30T00:01:04  *** justan0theruser has joined #bitcoin-core-dev
  2 2016-10-30T00:04:07  *** justanotheruser has quit IRC
  3 2016-10-30T00:10:28  *** fengling has quit IRC
  4 2016-10-30T00:15:44  *** AaronvanW has quit IRC
  5 2016-10-30T00:43:55  *** justan0theruser is now known as justanother|CHC
  6 2016-10-30T00:47:52  *** btcdrak has quit IRC
  7 2016-10-30T01:03:23  *** molz has joined #bitcoin-core-dev
  8 2016-10-30T01:05:11  *** cryptapus has quit IRC
  9 2016-10-30T01:06:18  *** moli has quit IRC
 10 2016-10-30T01:06:43  *** cryptapus has joined #bitcoin-core-dev
 11 2016-10-30T01:06:44  *** cryptapus has joined #bitcoin-core-dev
 12 2016-10-30T01:06:50  *** Giszmo has joined #bitcoin-core-dev
 13 2016-10-30T01:25:59  *** fengling has joined #bitcoin-core-dev
 14 2016-10-30T01:50:08  *** Ylbam has quit IRC
 15 2016-10-30T01:54:41  *** fengling has quit IRC
 16 2016-10-30T02:41:32  *** justanotheruser has joined #bitcoin-core-dev
 17 2016-10-30T02:44:18  *** justanother|CHC has quit IRC
 18 2016-10-30T03:58:17  *** rebroad has joined #bitcoin-core-dev
 19 2016-10-30T04:04:49  *** cryptapus is now known as cryptapus_afk
 20 2016-10-30T04:13:00  *** rebroad has quit IRC
 21 2016-10-30T04:24:08  *** aalex has quit IRC
 22 2016-10-30T04:26:32  *** justan0theruser has joined #bitcoin-core-dev
 23 2016-10-30T04:28:45  *** aalex has joined #bitcoin-core-dev
 24 2016-10-30T04:28:53  *** justanotheruser has quit IRC
 25 2016-10-30T04:55:11  *** Alopex has quit IRC
 26 2016-10-30T04:56:17  *** Alopex has joined #bitcoin-core-dev
 27 2016-10-30T05:12:45  *** Giszmo has quit IRC
 28 2016-10-30T05:35:38  *** juscamarena has quit IRC
 29 2016-10-30T05:36:37  *** btcdrak has joined #bitcoin-core-dev
 30 2016-10-30T06:31:48  *** wasi has joined #bitcoin-core-dev
 31 2016-10-30T06:33:02  *** rebroad has joined #bitcoin-core-dev
 32 2016-10-30T08:30:02  *** Ylbam has joined #bitcoin-core-dev
 33 2016-10-30T08:36:02  *** rebroad has quit IRC
 34 2016-10-30T08:57:59  *** AaronvanW has joined #bitcoin-core-dev
 35 2016-10-30T08:58:25  *** AaronvanW has quit IRC
 36 2016-10-30T08:58:25  *** AaronvanW has joined #bitcoin-core-dev
 37 2016-10-30T09:07:22  *** cdecker has joined #bitcoin-core-dev
 38 2016-10-30T09:32:57  *** Sosumi has joined #bitcoin-core-dev
 39 2016-10-30T09:36:46  *** Guyver2 has joined #bitcoin-core-dev
 40 2016-10-30T10:24:39  <wasi> great job on v0.13.1 guys. thanks to all the contributors for making this version a reality. looking forward to see the segwit sf happening.
 41 2016-10-30T11:14:26  *** JackH has joined #bitcoin-core-dev
 42 2016-10-30T11:41:47  *** laurentmt has joined #bitcoin-core-dev
 43 2016-10-30T12:20:09  *** Guyver2__ has joined #bitcoin-core-dev
 44 2016-10-30T12:20:26  *** Guyver2 has quit IRC
 45 2016-10-30T12:20:32  *** Guyver2__ is now known as Guyver2
 46 2016-10-30T12:27:14  <btcdrak> sipa: luke-jr: jonasschnelli: each of you dns seeds appear to be down.
 47 2016-10-30T12:29:19  *** goatpig has joined #bitcoin-core-dev
 48 2016-10-30T12:30:24  <goatpig> Are there specific rules to create SW outputs from legacy outputs? Can I just create a SW tx with empty witness programs, redeeming only legacy outputs? Do I have to use nested outputs in a legacy tx?
 49 2016-10-30T12:41:18  *** laurentmt has quit IRC
 50 2016-10-30T12:49:18  <phantomcircuit> goatpig: "from legacy outputs" huh?
 51 2016-10-30T12:52:54  *** laurentmt has joined #bitcoin-core-dev
 52 2016-10-30T12:56:02  <goatpig> phantomcircuit: current P2PKH and P2SH outputs
 53 2016-10-30T12:59:02  *** d9b4bef9 has quit IRC
 54 2016-10-30T13:00:08  *** d9b4bef9 has joined #bitcoin-core-dev
 55 2016-10-30T13:03:10  <jl2012> goatpig, current P2PKH and P2SH outputs will be spent in the old way
 56 2016-10-30T13:03:44  <jl2012> you may send to your own segwit-compliant address, of course
 57 2016-10-30T13:05:33  <goatpig> my concern is what is the preferred/legal path to convert a legacy output to a sw one
 58 2016-10-30T13:10:02  <Victorsueca> goatpig: I'd just make a standard transaction to send them to the segwit address
 59 2016-10-30T13:10:55  <aj> goatpig: same way you would upgrade from a legacy single-pubkey address to a 2-of-3 multisig address, you just spend the coin to your new address
 60 2016-10-30T13:13:21  <goatpig> ok so i dont have to force my users to spend to a nested sw first?
 61 2016-10-30T13:13:23  *** molz has quit IRC
 62 2016-10-30T13:17:27  <aj> goatpig: no, you don't have to. you'd save a step if you did though (which would be more efficient usage of the blockchain, and help free up tx space for other people to use)
 63 2016-10-30T13:18:34  *** moli has joined #bitcoin-core-dev
 64 2016-10-30T13:21:11  <goatpig> aj: you mean in their ability to provide non SW wallets with a way to pay into a SW output?
 65 2016-10-30T13:22:32  <goatpig> my plan was to ease my users into SW by defaulting change to SW outputs in the long run
 66 2016-10-30T13:23:31  <goatpig> im more concerned about migrating my users funds to SW than interfacing with non upgraded services
 67 2016-10-30T13:28:10  <GitHub39> [bitcoin] s-matthew-english opened pull request #9041: keypoololdest denote Unix epoch, not GMT (master...patch-8) https://github.com/bitcoin/bitcoin/pull/9041
 68 2016-10-30T13:28:46  <jl2012> goatpig, maybe using segwit output as change, but that hurts privacy
 69 2016-10-30T13:33:16  <goatpig> jl2012: how?
 70 2016-10-30T13:33:29  <goatpig> by revealing the change output?
 71 2016-10-30T13:33:59  <jl2012> it indicates which output is the change
 72 2016-10-30T13:34:27  <jl2012> but that's a chicken and egg problem
 73 2016-10-30T13:34:37  <goatpig> but that's basically the case as long as you have a mixed set of outputs
 74 2016-10-30T13:35:26  <goatpig> if you have only SW outputs and you are paying to a legacy output, the same privacy leak takes place
 75 2016-10-30T13:35:33  <aj> goatpig: you can give out an address for people to send money to you that looks like (is) a legacy P2SH address, but that you spend via segwit (ie saving tx fees when you spend it)
 76 2016-10-30T13:35:53  <aj> goatpig: if you have only SW outputs, you're not paying to a legacy output by definition?
 77 2016-10-30T13:36:11  <goatpig> aj: sure but it is less efficient that SW in that you still have to fulfill the p2sh script in the input before interpreting it as SW
 78 2016-10-30T13:36:35  <jl2012> goatpig: you could use native SW as change
 79 2016-10-30T13:36:36  <goatpig> aj: if someone requests a payment to a plain P2PKJ
 80 2016-10-30T13:36:39  <goatpig> P2PKH*
 81 2016-10-30T13:36:43  <goatpig> and i only have SW outputs
 82 2016-10-30T13:36:55  <goatpig> jl2012: that's what i want to run with so far
 83 2016-10-30T13:37:16  <goatpig> if the user wants "soft" SW conversion, send change to native P2WPKH
 84 2016-10-30T13:37:18  <aj> goatpig: then you're *inputs* (or prevouts) are SW, and one of your outputs is the P2PKH
 85 2016-10-30T13:37:19  <jl2012> SW outputs could be sent to anything, P2PKH or segwit
 86 2016-10-30T13:37:39  <goatpig> aj: yes, which is a privacy leak, in the light of jl2012 remarks
 87 2016-10-30T13:37:40  <aj> oops, "your"
 88 2016-10-30T13:38:32  <goatpig> jl2012: sure you can, but if your payee requests a legacy P2PKH payment, chances are his wallet isn't SW compliant
 89 2016-10-30T13:38:33  <jl2012> native SW is a even bigger privacy leak, because there is no address for that
 90 2016-10-30T13:38:40  <goatpig> and he won't see that payment if you force it to SW on your own
 91 2016-10-30T13:38:41  <aj> goatpig: there was a suggestion to have your change address be in the same form as one of the real outputs, so if you're spending to P2PKH, make your change address P2PKH...
 92 2016-10-30T13:38:57  <jl2012> goatpig: wallet doesn't verify txs, anyway
 93 2016-10-30T13:39:30  <jl2012> it's a softfork
 94 2016-10-30T13:39:51  <goatpig> jl2012: no but you are at best stuck with an output you can't spent, at worst you have a weird miscommunication where one end paid and the other lacks the software to aknowledge the payment
 95 2016-10-30T13:39:54  <jl2012> of course they will see it. That's the point of a softfork
 96 2016-10-30T13:40:34  <jl2012> the wallet should not care what the input is
 97 2016-10-30T13:40:43  <jl2012> they just care  what the output is
 98 2016-10-30T13:41:14  <jl2012> the input, for an unupgraded wallet, is anyone-can-spend
 99 2016-10-30T13:42:24  <goatpig> there's an argument to be made for non upgrade wallets, that they simply won't consider the output as theirs
100 2016-10-30T13:42:31  <goatpig> even P2WPKH
101 2016-10-30T13:42:59  <goatpig> as for native SW, i thought there was a spec for creating addresses out of those?
102 2016-10-30T13:43:35  <jl2012> if the payee gives you a P2PKH address, you must send to P2PKH, not P2WPKH
103 2016-10-30T13:43:45  <goatpig> of course
104 2016-10-30T13:43:52  <goatpig> if all my outputs however are P2WPKH
105 2016-10-30T13:43:54  <jl2012> so what's the problem?
106 2016-10-30T13:43:56  <goatpig> that's a privacy leak anyways
107 2016-10-30T13:44:04  <jl2012> P2WPKH could pay to P2PKH
108 2016-10-30T13:44:12  <goatpig> so taht goes back to using P2WPKH output change as default and the privacy leak
109 2016-10-30T13:44:36  <goatpig> wait
110 2016-10-30T13:44:41  <goatpig> im confusing a couple things here
111 2016-10-30T13:44:42  <goatpig> nvm
112 2016-10-30T13:44:55  <goatpig> although that's a bit annoying
113 2016-10-30T13:45:15  <goatpig> you'd be downgrading a SW output to a P2PKH change in that scenario
114 2016-10-30T13:45:30  <jl2012> that's by design
115 2016-10-30T13:45:41  <goatpig> ok
116 2016-10-30T13:45:52  <goatpig> what's the status on BIP142?
117 2016-10-30T13:46:21  <jl2012> i mean, it's up to your design. Or just let the user chooses
118 2016-10-30T13:46:39  <goatpig> more GUI complexity, sweet!
119 2016-10-30T13:46:49  <jl2012> expert mode
120 2016-10-30T13:46:59  <goatpig> i just hate working pyqt4
121 2016-10-30T13:48:19  <goatpig> anyways
122 2016-10-30T13:48:20  <jl2012> we have some discussion about the address design, like using BASE32
123 2016-10-30T13:48:46  <goatpig> wait so BIP142 isn't approved?
124 2016-10-30T13:48:57  <goatpig> and why the sudden change?
125 2016-10-30T14:03:32  <jl2012> many people hate BASE58
126 2016-10-30T14:04:16  <Victorsueca> is base32 like base58 but without caps?
127 2016-10-30T14:04:37  <jl2012> case-insensitive
128 2016-10-30T14:05:20  <Victorsueca> but addresses would be longer with base32 rigth?
129 2016-10-30T14:05:25  <Victorsueca> rigth*
130 2016-10-30T14:05:25  <jl2012> sure
131 2016-10-30T14:06:09  <jl2012> should be 17% longer with same amount of data
132 2016-10-30T14:06:25  <goatpig> is it gonna be a little flavored to avoid 0 and o? or i guess the case agnostic aspect covers that?
133 2016-10-30T14:06:54  <Victorsueca> goatpig: I think base 58 already avoids 0 and O
134 2016-10-30T14:07:10  <jl2012> there is some discussion to avoid bad word
135 2016-10-30T14:07:12  <goatpig> Victorsueca: it does, im wondering if the base 32 proposal is gonna
136 2016-10-30T14:07:32  <jl2012> but anyway, we could only take 4 characters away
137 2016-10-30T14:08:09  <Victorsueca> it would be base28 then
138 2016-10-30T14:08:37  <jl2012> no, 26 + 10 - 4 = 32
139 2016-10-30T14:08:46  <luke-jr> btcdrak: nothing wrong with my DNS seed, so must be on your end?
140 2016-10-30T14:08:46  <Victorsueca> ahh it's already counted
141 2016-10-30T14:09:07  <jl2012> so the question is which 4
142 2016-10-30T14:09:26  <Victorsueca> I would remove 0, O, I and i
143 2016-10-30T14:09:28  <jl2012> 1-L-I ; 0-O
144 2016-10-30T14:09:47  <jl2012> if you remove O, you may keep 0
145 2016-10-30T14:11:16  <goatpig> quick question about SW, can i create a SW tx but have all emtpy witness programs?
146 2016-10-30T14:12:04  <Victorsueca> goatpig: wouldn't e a segwit transaction at all
147 2016-10-30T14:12:08  <Victorsueca> be*
148 2016-10-30T14:12:26  <jl2012> you mean something like all inputs are P2PKH?
149 2016-10-30T14:12:45  <goatpig> jl2012: yup
150 2016-10-30T14:12:51  <goatpig> with with the marker and flag
151 2016-10-30T14:12:55  <jl2012> you must serialize it in the old way
152 2016-10-30T14:13:01  <goatpig> ok
153 2016-10-30T14:14:23  <jl2012> goatpig: this is a checklist for everything you need to do as wallet dev https://bitcoincore.org/en/segwit_wallet_dev/
154 2016-10-30T14:15:24  <btcdrak> luke-jr: is is not accessible from 3 geolocations I tried.
155 2016-10-30T14:16:42  <goatpig> jl2012: ive seen that but didnt go over it. thanks
156 2016-10-30T14:17:24  <jl2012> feel free to ask for clarification
157 2016-10-30T14:20:38  <goatpig> once i get the signer out of the way ill be back with more i expect
158 2016-10-30T14:20:55  <goatpig> thanks for the help =)
159 2016-10-30T14:33:56  *** paveljanik has joined #bitcoin-core-dev
160 2016-10-30T14:33:56  *** paveljanik has joined #bitcoin-core-dev
161 2016-10-30T14:58:16  <Victorsueca> does bitcoin core support 64-bit POSIX time?
162 2016-10-30T15:11:02  *** grubles has joined #bitcoin-core-dev
163 2016-10-30T15:15:36  *** grubles has quit IRC
164 2016-10-30T15:22:19  *** Guyver2 has quit IRC
165 2016-10-30T15:40:25  *** rebroad has joined #bitcoin-core-dev
166 2016-10-30T15:49:04  *** Giszmo has joined #bitcoin-core-dev
167 2016-10-30T16:06:40  *** tonikt has joined #bitcoin-core-dev
168 2016-10-30T16:08:19  <tonikt> Hi. Is there a way to find out whether "cmpctblock" message is version 1 or 2, just by looking into the content of the message?
169 2016-10-30T16:10:12  <GitHub141> [bitcoin] MarcoFalke opened pull request #9042: [rpc] ParseHash: Fail when length is not 64 (master...Mf1611-rpcParseHash64) https://github.com/bitcoin/bitcoin/pull/9042
170 2016-10-30T16:11:39  *** MarcoFalke has joined #bitcoin-core-dev
171 2016-10-30T16:21:12  *** rebroad has quit IRC
172 2016-10-30T16:56:01  *** alina-malina has quit IRC
173 2016-10-30T17:03:28  *** Alina-malina has joined #bitcoin-core-dev
174 2016-10-30T17:05:07  *** Alina-malina has quit IRC
175 2016-10-30T17:05:07  *** Alina-malina has joined #bitcoin-core-dev
176 2016-10-30T17:27:59  <GitHub107> [bitcoin] MarcoFalke opened pull request #9043: [qt] Return useful error message on ATMP failure (master...Mf1611-qtATMPerror) https://github.com/bitcoin/bitcoin/pull/9043
177 2016-10-30T17:32:23  <luke-jr> btcdrak: well, others seem to hit it fine
178 2016-10-30T17:32:34  <sipa> tonikt: no
179 2016-10-30T17:32:41  <luke-jr> Victorsueca: kinda has to, to work on x86_64 Linux
180 2016-10-30T17:33:17  <luke-jr> sipa: hmm, I understand why that is, but maybe it's going to make life hard for Wireshark >_<
181 2016-10-30T17:34:16  <sipa> luke-jr: well thankfully the data inside is very similar
182 2016-10-30T17:34:48  <sipa> 2 uses wtxid and can contains witnesses in transactions
183 2016-10-30T17:34:56  <sipa> 1 uses txid and can't
184 2016-10-30T17:35:48  <luke-jr> yes, but maybe something to keep in mind for future versions
185 2016-10-30T17:36:29  <sipa> agree
186 2016-10-30T17:47:36  *** LeMiner has quit IRC
187 2016-10-30T17:57:01  *** wasi has quit IRC
188 2016-10-30T17:57:21  *** MarcoFalke has left #bitcoin-core-dev
189 2016-10-30T18:06:43  *** whphhg has quit IRC
190 2016-10-30T18:25:39  <GitHub139> [bitcoin] paveljanik closed pull request #8468: Do not shadow member variables in serialization (master...20160805_Wshadow_serialization) https://github.com/bitcoin/bitcoin/pull/8468
191 2016-10-30T18:31:42  *** LeMiner has joined #bitcoin-core-dev
192 2016-10-30T18:52:36  <petertodd> sipa: ah cool, I was having problems with 100% cpu usage; my vps provider kept turning the seed node off
193 2016-10-30T18:52:59  *** wasi has joined #bitcoin-core-dev
194 2016-10-30T19:42:36  *** laurentmt has quit IRC
195 2016-10-30T20:39:01  *** CubicEarth has joined #bitcoin-core-dev
196 2016-10-30T20:40:12  *** CubicEarth has quit IRC
197 2016-10-30T21:24:35  *** aalex has quit IRC
198 2016-10-30T21:28:26  *** aalex has joined #bitcoin-core-dev
199 2016-10-30T21:41:01  *** CubicEarth has joined #bitcoin-core-dev
200 2016-10-30T21:46:47  *** CubicEarth has quit IRC
201 2016-10-30T21:49:26  <midnightmagic> hah, hilarious: <sipa>    wow, mtgox almost reached $0.5
202 2016-10-30T21:49:28  <midnightmagic> oldschool
203 2016-10-30T21:50:21  <sipa> date?
204 2016-10-30T22:05:08  <Lightsword> hmm, anyone seeing a bunch of spy nodes from AWS? I’m seeing a pattern of 3 connections per IP to my node
205 2016-10-30T22:05:24  <BlueMatt> thoughts on https://github.com/TheBlueMatt/bitcoin/commit/fe1dc62cef88280d2490a619beded052f313c6fc ?
206 2016-10-30T22:05:52  <BlueMatt> lightningbot: 3 connections seems low...theres been a bunch of deanonymisation services doing like 10/30 per IP from aws
207 2016-10-30T22:05:52  <lightningbot> BlueMatt: Error: "3" is not a valid command.
208 2016-10-30T22:05:59  <BlueMatt> ehh, Lightsword
209 2016-10-30T22:06:14  <Lightsword> BlueMatt, 3 connections per IP, but many sets of 3
210 2016-10-30T22:06:27  <BlueMatt> yea, thats some deanonmization attack services
211 2016-10-30T22:06:58  <Lightsword> BlueMatt, yeah and it’s bitcoinj which normally gets kicked since I block bloom filters
212 2016-10-30T22:07:22  <BlueMatt> its obviously bullshit bitcoinj, because they claim to be actual wallets (multibit, etc) but dont send bloom filters :p
213 2016-10-30T22:07:36  <BlueMatt> i mean, yes, probably based on bitcoinj, but obviously not real wallets
214 2016-10-30T22:07:44  <sipa> BlueMatt: looks good. no need to do hashing in the message processing thread
215 2016-10-30T22:07:50  <Lightsword> BlueMatt, yep, there a good way to filter those out?
216 2016-10-30T22:08:09  <BlueMatt> Lightsword: ban them? run a script to ban anything that looks like /bitcoinj :p
217 2016-10-30T22:09:20  <BlueMatt> sipa: ok, pr'd
218 2016-10-30T22:09:30  <GitHub178> [bitcoin] TheBlueMatt opened pull request #9045: Hash P2P messages as they are received instead of at process-time (master...2016-10-p2p-hash) https://github.com/bitcoin/bitcoin/pull/9045
219 2016-10-30T22:12:30  <Lightsword> BlueMatt, won’t they just fake useragent if I do that? is there an easy way to ban all clients that aren’t full nodes or is that hard to determine?
220 2016-10-30T22:12:35  <sipa> BlueMatt: i'm a bit surprised we weren't doing that already, actually :)
221 2016-10-30T22:12:42  <BlueMatt> sipa: i was as well
222 2016-10-30T22:12:55  <BlueMatt> Lightsword: well at least it'll fix it temporarily :p
223 2016-10-30T22:13:20  <BlueMatt> Lightsword: you could hack your shit up to request a recent block on connection and ban if they dont respond?
224 2016-10-30T22:19:42  <gmaxwell> Lightsword: I put up a ban list previously.
225 2016-10-30T22:20:00  <gmaxwell> http://0bin.net/paste/V0GAccklhV+huNVC#8uKrkZB0NYEHakf+GEf6Bz7995wvwjpYiYddPzAU71e
226 2016-10-30T22:22:31  <Lightsword> gmaxwell, thanks, think that got most of them
227 2016-10-30T22:23:15  *** CubicEarth has joined #bitcoin-core-dev
228 2016-10-30T22:23:42  <gmaxwell> 128.101.34.77 is another I've seen more recently.
229 2016-10-30T22:24:14  *** Ylbam has quit IRC
230 2016-10-30T22:24:16  <sipa> gmaxwell: university of minnesota?
231 2016-10-30T22:24:34  *** Ylbam has joined #bitcoin-core-dev
232 2016-10-30T22:25:46  <Lightsword> any idea why they open 3 connections per IP?
233 2016-10-30T22:26:18  <gmaxwell> they're trying to bypass the relay privacy protections.
234 2016-10-30T22:26:36  <gmaxwell> right now we leak somewhat more information if you make more connections.
235 2016-10-30T22:27:01  <gmaxwell> We should fix that.  (I knew that when I put in the currency scheme, but it was better than what we had)
236 2016-10-30T22:34:13  <CubicEarth> Good day! Does anyone know of a protocol / standard so that wallets from different developers can work together in the creation of a multi-sig address?
237 2016-10-30T22:39:09  *** cdecker has quit IRC
238 2016-10-30T22:51:31  <Victorsueca> Lightsword: I just banned the whole 52.0.0.0/8 space
239 2016-10-30T22:51:47  <Victorsueca> that will get you rid of most of them
240 2016-10-30T22:59:28  <TD-Linux> that's effectively all of aws, clearly not a very sustainable solution
241 2016-10-30T23:04:05  *** tulip has joined #bitcoin-core-dev
242 2016-10-30T23:05:12  <sipa> only 45% of AWE
243 2016-10-30T23:05:20  <tulip> none of this is sustainable really. rightward suggested an aliveness test by asking for a block from them, but there's already software which transparently proxies these requests to other peers on the network. it's not feasible to IP ban (because they will evade it with more distributed IPs), if we ban on services on subversions they will just change them.
244 2016-10-30T23:05:23  <sipa> only 45% of AWS's IPv4 space is under 54/*
245 2016-10-30T23:05:31  <tulip> s/rightward/lightsword
246 2016-10-30T23:05:32  <sipa> oh, 52
247 2016-10-30T23:06:13  <sipa> 36% is under 52/*
248 2016-10-30T23:07:37  <BlueMatt> argh, whens the next block :(
249 2016-10-30T23:08:37  <tulip> BlueMatt: 10 minutes time.
250 2016-10-30T23:11:51  <tulip> there's no clear solution to these sybil nodes, regardless. the core problem is they obviously have a huge amount of money to spend attacking the network, and consequently you could assume they're getting results if they're continuing to spend money on this regardless.
251 2016-10-30T23:12:31  <BlueMatt> well the obvious solution is to fix the bug they're exploiting
252 2016-10-30T23:12:47  <BlueMatt> if there is no gain from them connecting 10x to each node then hopefully they will go away
253 2016-10-30T23:13:43  <sipa> is there a reason to assume that hosts in multiple netgroups are harder to obtain than individual ips?
254 2016-10-30T23:14:06  <BlueMatt> not harder, just more effort and maybe 1.5x cost
255 2016-10-30T23:14:12  <BlueMatt> well, not hard
256 2016-10-30T23:14:19  <BlueMatt> tiny bit more effort, not a ton, though
257 2016-10-30T23:14:28  <sipa> s/harder/costlier/
258 2016-10-30T23:15:01  <BlueMatt> usually a host will sell you extra ips for reasonably cheap compared to another host somewhere else
259 2016-10-30T23:15:15  <BlueMatt> but a host that is just proxying traffic is also dirt cheap
260 2016-10-30T23:16:08  <sipa> otherwise an easy solution would be to use deterministic randomness for the inv push events based on netgroup
261 2016-10-30T23:16:28  <sipa> so nodes within the same netgroup will see correlated sends
262 2016-10-30T23:17:05  <BlueMatt> bucketed-announces to most peers is probably the way to go?
263 2016-10-30T23:17:34  <BlueMatt> it has plenty of issues itself, but at least it solves this specific problem
264 2016-10-30T23:18:48  <sipa> what do you mean?
265 2016-10-30T23:20:17  <BlueMatt> gmaxwell's original suggestion of announce live only to eg two statically-selected peers and to the rest, batch inv announcements eg announce every 30 seconds the previous 30 seconds worth of txn you saw
266 2016-10-30T23:22:38  <BlueMatt> still has correlation issues since prop. is relatively deterministic, but it solves the issue we have now, and you could randomly delay the ~3 peers to which you announce live, as we do now
267 2016-10-30T23:23:32  <gmaxwell> there are providers that will give you IPs in diverse /8s (even better than /16s) basically for the purpose of tracing users in varrious DHT schemes.
268 2016-10-30T23:24:28  <BlueMatt> heh, cool
269 2016-10-30T23:27:52  <gmaxwell> I've never priced it out but I assume it's not horiffically expensive compared to what that one attacker is spending on ec2 costs already.
270 2016-10-30T23:28:32  <BlueMatt> I'm sure it cant be too much more expensive
271 2016-10-30T23:28:42  <BlueMatt> aws is stupid expensive
272 2016-10-30T23:39:41  *** CubicEarth has quit IRC
273 2016-10-30T23:44:23  *** CyrusV has left #bitcoin-core-dev