12016-10-30T00:01:04  *** justan0theruser has joined #bitcoin-core-dev
  22016-10-30T00:04:07  *** justanotheruser has quit IRC
  32016-10-30T00:10:28  *** fengling has quit IRC
  42016-10-30T00:15:44  *** AaronvanW has quit IRC
  52016-10-30T00:43:55  *** justan0theruser is now known as justanother|CHC
  62016-10-30T00:47:52  *** btcdrak has quit IRC
  72016-10-30T01:03:23  *** molz has joined #bitcoin-core-dev
  82016-10-30T01:05:11  *** cryptapus has quit IRC
  92016-10-30T01:06:18  *** moli has quit IRC
 102016-10-30T01:06:43  *** cryptapus has joined #bitcoin-core-dev
 112016-10-30T01:06:44  *** cryptapus has joined #bitcoin-core-dev
 122016-10-30T01:06:50  *** Giszmo has joined #bitcoin-core-dev
 132016-10-30T01:25:59  *** fengling has joined #bitcoin-core-dev
 142016-10-30T01:50:08  *** Ylbam has quit IRC
 152016-10-30T01:54:41  *** fengling has quit IRC
 162016-10-30T02:41:32  *** justanotheruser has joined #bitcoin-core-dev
 172016-10-30T02:44:18  *** justanother|CHC has quit IRC
 182016-10-30T03:58:17  *** rebroad has joined #bitcoin-core-dev
 192016-10-30T04:04:49  *** cryptapus is now known as cryptapus_afk
 202016-10-30T04:13:00  *** rebroad has quit IRC
 212016-10-30T04:24:08  *** aalex has quit IRC
 222016-10-30T04:26:32  *** justan0theruser has joined #bitcoin-core-dev
 232016-10-30T04:28:45  *** aalex has joined #bitcoin-core-dev
 242016-10-30T04:28:53  *** justanotheruser has quit IRC
 252016-10-30T04:55:11  *** Alopex has quit IRC
 262016-10-30T04:56:17  *** Alopex has joined #bitcoin-core-dev
 272016-10-30T05:12:45  *** Giszmo has quit IRC
 282016-10-30T05:35:38  *** juscamarena has quit IRC
 292016-10-30T05:36:37  *** btcdrak has joined #bitcoin-core-dev
 302016-10-30T06:31:48  *** wasi has joined #bitcoin-core-dev
 312016-10-30T06:33:02  *** rebroad has joined #bitcoin-core-dev
 322016-10-30T08:30:02  *** Ylbam has joined #bitcoin-core-dev
 332016-10-30T08:36:02  *** rebroad has quit IRC
 342016-10-30T08:57:59  *** AaronvanW has joined #bitcoin-core-dev
 352016-10-30T08:58:25  *** AaronvanW has quit IRC
 362016-10-30T08:58:25  *** AaronvanW has joined #bitcoin-core-dev
 372016-10-30T09:07:22  *** cdecker has joined #bitcoin-core-dev
 382016-10-30T09:32:57  *** Sosumi has joined #bitcoin-core-dev
 392016-10-30T09:36:46  *** Guyver2 has joined #bitcoin-core-dev
 402016-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.
 412016-10-30T11:14:26  *** JackH has joined #bitcoin-core-dev
 422016-10-30T11:41:47  *** laurentmt has joined #bitcoin-core-dev
 432016-10-30T12:20:09  *** Guyver2__ has joined #bitcoin-core-dev
 442016-10-30T12:20:26  *** Guyver2 has quit IRC
 452016-10-30T12:20:32  *** Guyver2__ is now known as Guyver2
 462016-10-30T12:27:14  <btcdrak> sipa: luke-jr: jonasschnelli: each of you dns seeds appear to be down.
 472016-10-30T12:29:19  *** goatpig has joined #bitcoin-core-dev
 482016-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?
 492016-10-30T12:41:18  *** laurentmt has quit IRC
 502016-10-30T12:49:18  <phantomcircuit> goatpig: "from legacy outputs" huh?
 512016-10-30T12:52:54  *** laurentmt has joined #bitcoin-core-dev
 522016-10-30T12:56:02  <goatpig> phantomcircuit: current P2PKH and P2SH outputs
 532016-10-30T12:59:02  *** d9b4bef9 has quit IRC
 542016-10-30T13:00:08  *** d9b4bef9 has joined #bitcoin-core-dev
 552016-10-30T13:03:10  <jl2012> goatpig, current P2PKH and P2SH outputs will be spent in the old way
 562016-10-30T13:03:44  <jl2012> you may send to your own segwit-compliant address, of course
 572016-10-30T13:05:33  <goatpig> my concern is what is the preferred/legal path to convert a legacy output to a sw one
 582016-10-30T13:10:02  <Victorsueca> goatpig: I'd just make a standard transaction to send them to the segwit address
 592016-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
 602016-10-30T13:13:21  <goatpig> ok so i dont have to force my users to spend to a nested sw first?
 612016-10-30T13:13:23  *** molz has quit IRC
 622016-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)
 632016-10-30T13:18:34  *** moli has joined #bitcoin-core-dev
 642016-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?
 652016-10-30T13:22:32  <goatpig> my plan was to ease my users into SW by defaulting change to SW outputs in the long run
 662016-10-30T13:23:31  <goatpig> im more concerned about migrating my users funds to SW than interfacing with non upgraded services
 672016-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
 682016-10-30T13:28:46  <jl2012> goatpig, maybe using segwit output as change, but that hurts privacy
 692016-10-30T13:33:16  <goatpig> jl2012: how?
 702016-10-30T13:33:29  <goatpig> by revealing the change output?
 712016-10-30T13:33:59  <jl2012> it indicates which output is the change
 722016-10-30T13:34:27  <jl2012> but that's a chicken and egg problem
 732016-10-30T13:34:37  <goatpig> but that's basically the case as long as you have a mixed set of outputs
 742016-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
 752016-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)
 762016-10-30T13:35:53  <aj> goatpig: if you have only SW outputs, you're not paying to a legacy output by definition?
 772016-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
 782016-10-30T13:36:35  <jl2012> goatpig: you could use native SW as change
 792016-10-30T13:36:36  <goatpig> aj: if someone requests a payment to a plain P2PKJ
 802016-10-30T13:36:39  <goatpig> P2PKH*
 812016-10-30T13:36:43  <goatpig> and i only have SW outputs
 822016-10-30T13:36:55  <goatpig> jl2012: that's what i want to run with so far
 832016-10-30T13:37:16  <goatpig> if the user wants "soft" SW conversion, send change to native P2WPKH
 842016-10-30T13:37:18  <aj> goatpig: then you're *inputs* (or prevouts) are SW, and one of your outputs is the P2PKH
 852016-10-30T13:37:19  <jl2012> SW outputs could be sent to anything, P2PKH or segwit
 862016-10-30T13:37:39  <goatpig> aj: yes, which is a privacy leak, in the light of jl2012 remarks
 872016-10-30T13:37:40  <aj> oops, "your"
 882016-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
 892016-10-30T13:38:33  <jl2012> native SW is a even bigger privacy leak, because there is no address for that
 902016-10-30T13:38:40  <goatpig> and he won't see that payment if you force it to SW on your own
 912016-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...
 922016-10-30T13:38:57  <jl2012> goatpig: wallet doesn't verify txs, anyway
 932016-10-30T13:39:30  <jl2012> it's a softfork
 942016-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
 952016-10-30T13:39:54  <jl2012> of course they will see it. That's the point of a softfork
 962016-10-30T13:40:34  <jl2012> the wallet should not care what the input is
 972016-10-30T13:40:43  <jl2012> they just care  what the output is
 982016-10-30T13:41:14  <jl2012> the input, for an unupgraded wallet, is anyone-can-spend
 992016-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
1002016-10-30T13:42:31  <goatpig> even P2WPKH
1012016-10-30T13:42:59  <goatpig> as for native SW, i thought there was a spec for creating addresses out of those?
1022016-10-30T13:43:35  <jl2012> if the payee gives you a P2PKH address, you must send to P2PKH, not P2WPKH
1032016-10-30T13:43:45  <goatpig> of course
1042016-10-30T13:43:52  <goatpig> if all my outputs however are P2WPKH
1052016-10-30T13:43:54  <jl2012> so what's the problem?
1062016-10-30T13:43:56  <goatpig> that's a privacy leak anyways
1072016-10-30T13:44:04  <jl2012> P2WPKH could pay to P2PKH
1082016-10-30T13:44:12  <goatpig> so taht goes back to using P2WPKH output change as default and the privacy leak
1092016-10-30T13:44:36  <goatpig> wait
1102016-10-30T13:44:41  <goatpig> im confusing a couple things here
1112016-10-30T13:44:42  <goatpig> nvm
1122016-10-30T13:44:55  <goatpig> although that's a bit annoying
1132016-10-30T13:45:15  <goatpig> you'd be downgrading a SW output to a P2PKH change in that scenario
1142016-10-30T13:45:30  <jl2012> that's by design
1152016-10-30T13:45:41  <goatpig> ok
1162016-10-30T13:45:52  <goatpig> what's the status on BIP142?
1172016-10-30T13:46:21  <jl2012> i mean, it's up to your design. Or just let the user chooses
1182016-10-30T13:46:39  <goatpig> more GUI complexity, sweet!
1192016-10-30T13:46:49  <jl2012> expert mode
1202016-10-30T13:46:59  <goatpig> i just hate working pyqt4
1212016-10-30T13:48:19  <goatpig> anyways
1222016-10-30T13:48:20  <jl2012> we have some discussion about the address design, like using BASE32
1232016-10-30T13:48:46  <goatpig> wait so BIP142 isn't approved?
1242016-10-30T13:48:57  <goatpig> and why the sudden change?
1252016-10-30T14:03:32  <jl2012> many people hate BASE58
1262016-10-30T14:04:16  <Victorsueca> is base32 like base58 but without caps?
1272016-10-30T14:04:37  <jl2012> case-insensitive
1282016-10-30T14:05:20  <Victorsueca> but addresses would be longer with base32 rigth?
1292016-10-30T14:05:25  <Victorsueca> rigth*
1302016-10-30T14:05:25  <jl2012> sure
1312016-10-30T14:06:09  <jl2012> should be 17% longer with same amount of data
1322016-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?
1332016-10-30T14:06:54  <Victorsueca> goatpig: I think base 58 already avoids 0 and O
1342016-10-30T14:07:10  <jl2012> there is some discussion to avoid bad word
1352016-10-30T14:07:12  <goatpig> Victorsueca: it does, im wondering if the base 32 proposal is gonna
1362016-10-30T14:07:32  <jl2012> but anyway, we could only take 4 characters away
1372016-10-30T14:08:09  <Victorsueca> it would be base28 then
1382016-10-30T14:08:37  <jl2012> no, 26 + 10 - 4 = 32
1392016-10-30T14:08:46  <luke-jr> btcdrak: nothing wrong with my DNS seed, so must be on your end?
1402016-10-30T14:08:46  <Victorsueca> ahh it's already counted
1412016-10-30T14:09:07  <jl2012> so the question is which 4
1422016-10-30T14:09:26  <Victorsueca> I would remove 0, O, I and i
1432016-10-30T14:09:28  <jl2012> 1-L-I ; 0-O
1442016-10-30T14:09:47  <jl2012> if you remove O, you may keep 0
1452016-10-30T14:11:16  <goatpig> quick question about SW, can i create a SW tx but have all emtpy witness programs?
1462016-10-30T14:12:04  <Victorsueca> goatpig: wouldn't e a segwit transaction at all
1472016-10-30T14:12:08  <Victorsueca> be*
1482016-10-30T14:12:26  <jl2012> you mean something like all inputs are P2PKH?
1492016-10-30T14:12:45  <goatpig> jl2012: yup
1502016-10-30T14:12:51  <goatpig> with with the marker and flag
1512016-10-30T14:12:55  <jl2012> you must serialize it in the old way
1522016-10-30T14:13:01  <goatpig> ok
1532016-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/
1542016-10-30T14:15:24  <btcdrak> luke-jr: is is not accessible from 3 geolocations I tried.
1552016-10-30T14:16:42  <goatpig> jl2012: ive seen that but didnt go over it. thanks
1562016-10-30T14:17:24  <jl2012> feel free to ask for clarification
1572016-10-30T14:20:38  <goatpig> once i get the signer out of the way ill be back with more i expect
1582016-10-30T14:20:55  <goatpig> thanks for the help =)
1592016-10-30T14:33:56  *** paveljanik has joined #bitcoin-core-dev
1602016-10-30T14:33:56  *** paveljanik has joined #bitcoin-core-dev
1612016-10-30T14:58:16  <Victorsueca> does bitcoin core support 64-bit POSIX time?
1622016-10-30T15:11:02  *** grubles has joined #bitcoin-core-dev
1632016-10-30T15:15:36  *** grubles has quit IRC
1642016-10-30T15:22:19  *** Guyver2 has quit IRC
1652016-10-30T15:40:25  *** rebroad has joined #bitcoin-core-dev
1662016-10-30T15:49:04  *** Giszmo has joined #bitcoin-core-dev
1672016-10-30T16:06:40  *** tonikt has joined #bitcoin-core-dev
1682016-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?
1692016-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
1702016-10-30T16:11:39  *** MarcoFalke has joined #bitcoin-core-dev
1712016-10-30T16:21:12  *** rebroad has quit IRC
1722016-10-30T16:56:01  *** alina-malina has quit IRC
1732016-10-30T17:03:28  *** Alina-malina has joined #bitcoin-core-dev
1742016-10-30T17:05:07  *** Alina-malina has quit IRC
1752016-10-30T17:05:07  *** Alina-malina has joined #bitcoin-core-dev
1762016-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
1772016-10-30T17:32:23  <luke-jr> btcdrak: well, others seem to hit it fine
1782016-10-30T17:32:34  <sipa> tonikt: no
1792016-10-30T17:32:41  <luke-jr> Victorsueca: kinda has to, to work on x86_64 Linux
1802016-10-30T17:33:17  <luke-jr> sipa: hmm, I understand why that is, but maybe it's going to make life hard for Wireshark >_<
1812016-10-30T17:34:16  <sipa> luke-jr: well thankfully the data inside is very similar
1822016-10-30T17:34:48  <sipa> 2 uses wtxid and can contains witnesses in transactions
1832016-10-30T17:34:56  <sipa> 1 uses txid and can't
1842016-10-30T17:35:48  <luke-jr> yes, but maybe something to keep in mind for future versions
1852016-10-30T17:36:29  <sipa> agree
1862016-10-30T17:47:36  *** LeMiner has quit IRC
1872016-10-30T17:57:01  *** wasi has quit IRC
1882016-10-30T17:57:21  *** MarcoFalke has left #bitcoin-core-dev
1892016-10-30T18:06:43  *** whphhg has quit IRC
1902016-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
1912016-10-30T18:31:42  *** LeMiner has joined #bitcoin-core-dev
1922016-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
1932016-10-30T18:52:59  *** wasi has joined #bitcoin-core-dev
1942016-10-30T19:42:36  *** laurentmt has quit IRC
1952016-10-30T20:39:01  *** CubicEarth has joined #bitcoin-core-dev
1962016-10-30T20:40:12  *** CubicEarth has quit IRC
1972016-10-30T21:24:35  *** aalex has quit IRC
1982016-10-30T21:28:26  *** aalex has joined #bitcoin-core-dev
1992016-10-30T21:41:01  *** CubicEarth has joined #bitcoin-core-dev
2002016-10-30T21:46:47  *** CubicEarth has quit IRC
2012016-10-30T21:49:26  <midnightmagic> hah, hilarious: <sipa>    wow, mtgox almost reached $0.5
2022016-10-30T21:49:28  <midnightmagic> oldschool
2032016-10-30T21:50:21  <sipa> date?
2042016-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
2052016-10-30T22:05:24  <BlueMatt> thoughts on https://github.com/TheBlueMatt/bitcoin/commit/fe1dc62cef88280d2490a619beded052f313c6fc ?
2062016-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
2072016-10-30T22:05:52  <lightningbot> BlueMatt: Error: "3" is not a valid command.
2082016-10-30T22:05:59  <BlueMatt> ehh, Lightsword
2092016-10-30T22:06:14  <Lightsword> BlueMatt, 3 connections per IP, but many sets of 3
2102016-10-30T22:06:27  <BlueMatt> yea, thats some deanonmization attack services
2112016-10-30T22:06:58  <Lightsword> BlueMatt, yeah and it’s bitcoinj which normally gets kicked since I block bloom filters
2122016-10-30T22:07:22  <BlueMatt> its obviously bullshit bitcoinj, because they claim to be actual wallets (multibit, etc) but dont send bloom filters :p
2132016-10-30T22:07:36  <BlueMatt> i mean, yes, probably based on bitcoinj, but obviously not real wallets
2142016-10-30T22:07:44  <sipa> BlueMatt: looks good. no need to do hashing in the message processing thread
2152016-10-30T22:07:50  <Lightsword> BlueMatt, yep, there a good way to filter those out?
2162016-10-30T22:08:09  <BlueMatt> Lightsword: ban them? run a script to ban anything that looks like /bitcoinj :p
2172016-10-30T22:09:20  <BlueMatt> sipa: ok, pr'd
2182016-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
2192016-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?
2202016-10-30T22:12:35  <sipa> BlueMatt: i'm a bit surprised we weren't doing that already, actually :)
2212016-10-30T22:12:42  <BlueMatt> sipa: i was as well
2222016-10-30T22:12:55  <BlueMatt> Lightsword: well at least it'll fix it temporarily :p
2232016-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?
2242016-10-30T22:19:42  <gmaxwell> Lightsword: I put up a ban list previously.
2252016-10-30T22:20:00  <gmaxwell> http://0bin.net/paste/V0GAccklhV+huNVC#8uKrkZB0NYEHakf+GEf6Bz7995wvwjpYiYddPzAU71e
2262016-10-30T22:22:31  <Lightsword> gmaxwell, thanks, think that got most of them
2272016-10-30T22:23:15  *** CubicEarth has joined #bitcoin-core-dev
2282016-10-30T22:23:42  <gmaxwell> 128.101.34.77 is another I've seen more recently.
2292016-10-30T22:24:14  *** Ylbam has quit IRC
2302016-10-30T22:24:16  <sipa> gmaxwell: university of minnesota?
2312016-10-30T22:24:34  *** Ylbam has joined #bitcoin-core-dev
2322016-10-30T22:25:46  <Lightsword> any idea why they open 3 connections per IP?
2332016-10-30T22:26:18  <gmaxwell> they're trying to bypass the relay privacy protections.
2342016-10-30T22:26:36  <gmaxwell> right now we leak somewhat more information if you make more connections.
2352016-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)
2362016-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?
2372016-10-30T22:39:09  *** cdecker has quit IRC
2382016-10-30T22:51:31  <Victorsueca> Lightsword: I just banned the whole 52.0.0.0/8 space
2392016-10-30T22:51:47  <Victorsueca> that will get you rid of most of them
2402016-10-30T22:59:28  <TD-Linux> that's effectively all of aws, clearly not a very sustainable solution
2412016-10-30T23:04:05  *** tulip has joined #bitcoin-core-dev
2422016-10-30T23:05:12  <sipa> only 45% of AWE
2432016-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.
2442016-10-30T23:05:23  <sipa> only 45% of AWS's IPv4 space is under 54/*
2452016-10-30T23:05:31  <tulip> s/rightward/lightsword
2462016-10-30T23:05:32  <sipa> oh, 52
2472016-10-30T23:06:13  <sipa> 36% is under 52/*
2482016-10-30T23:07:37  <BlueMatt> argh, whens the next block :(
2492016-10-30T23:08:37  <tulip> BlueMatt: 10 minutes time.
2502016-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.
2512016-10-30T23:12:31  <BlueMatt> well the obvious solution is to fix the bug they're exploiting
2522016-10-30T23:12:47  <BlueMatt> if there is no gain from them connecting 10x to each node then hopefully they will go away
2532016-10-30T23:13:43  <sipa> is there a reason to assume that hosts in multiple netgroups are harder to obtain than individual ips?
2542016-10-30T23:14:06  <BlueMatt> not harder, just more effort and maybe 1.5x cost
2552016-10-30T23:14:12  <BlueMatt> well, not hard
2562016-10-30T23:14:19  <BlueMatt> tiny bit more effort, not a ton, though
2572016-10-30T23:14:28  <sipa> s/harder/costlier/
2582016-10-30T23:15:01  <BlueMatt> usually a host will sell you extra ips for reasonably cheap compared to another host somewhere else
2592016-10-30T23:15:15  <BlueMatt> but a host that is just proxying traffic is also dirt cheap
2602016-10-30T23:16:08  <sipa> otherwise an easy solution would be to use deterministic randomness for the inv push events based on netgroup
2612016-10-30T23:16:28  <sipa> so nodes within the same netgroup will see correlated sends
2622016-10-30T23:17:05  <BlueMatt> bucketed-announces to most peers is probably the way to go?
2632016-10-30T23:17:34  <BlueMatt> it has plenty of issues itself, but at least it solves this specific problem
2642016-10-30T23:18:48  <sipa> what do you mean?
2652016-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
2662016-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
2672016-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.
2682016-10-30T23:24:28  <BlueMatt> heh, cool
2692016-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.
2702016-10-30T23:28:32  <BlueMatt> I'm sure it cant be too much more expensive
2712016-10-30T23:28:42  <BlueMatt> aws is stupid expensive
2722016-10-30T23:39:41  *** CubicEarth has quit IRC
2732016-10-30T23:44:23  *** CyrusV has left #bitcoin-core-dev