1 2016-10-30 10:24:39	0|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.
  2 2016-10-30 12:27:15	0|btcdrak|sipa: luke-jr: jonasschnelli: each of you dns seeds appear to be down.
  3 2016-10-30 12:30:24	0|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?
  4 2016-10-30 12:49:19	0|phantomcircuit|goatpig: "from legacy outputs" huh?
  5 2016-10-30 12:56:03	0|goatpig|phantomcircuit: current P2PKH and P2SH outputs
  6 2016-10-30 13:03:10	0|jl2012|goatpig, current P2PKH and P2SH outputs will be spent in the old way
  7 2016-10-30 13:03:44	0|jl2012|you may send to your own segwit-compliant address, of course
  8 2016-10-30 13:05:34	0|goatpig|my concern is what is the preferred/legal path to convert a legacy output to a sw one
  9 2016-10-30 13:10:02	0|Victorsueca|goatpig: I'd just make a standard transaction to send them to the segwit address
 10 2016-10-30 13:10:55	0|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
 11 2016-10-30 13:13:21	0|goatpig|ok so i dont have to force my users to spend to a nested sw first?
 12 2016-10-30 13:17:27	0|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)
 13 2016-10-30 13:21:11	0|goatpig|aj: you mean in their ability to provide non SW wallets with a way to pay into a SW output?
 14 2016-10-30 13:22:32	0|goatpig|my plan was to ease my users into SW by defaulting change to SW outputs in the long run
 15 2016-10-30 13:23:31	0|goatpig|im more concerned about migrating my users funds to SW than interfacing with non upgraded services
 16 2016-10-30 13:28:11	0|GitHub39|[13bitcoin] 15s-matthew-english opened pull request #9041: keypoololdest denote Unix epoch, not GMT (06master...06patch-8) 02https://github.com/bitcoin/bitcoin/pull/9041
 17 2016-10-30 13:28:46	0|jl2012|goatpig, maybe using segwit output as change, but that hurts privacy
 18 2016-10-30 13:33:17	0|goatpig|jl2012: how?
 19 2016-10-30 13:33:29	0|goatpig|by revealing the change output?
 20 2016-10-30 13:34:00	0|jl2012|it indicates which output is the change
 21 2016-10-30 13:34:28	0|jl2012|but that's a chicken and egg problem
 22 2016-10-30 13:34:38	0|goatpig|but that's basically the case as long as you have a mixed set of outputs
 23 2016-10-30 13:35:26	0|goatpig|if you have only SW outputs and you are paying to a legacy output, the same privacy leak takes place
 24 2016-10-30 13:35:33	0|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)
 25 2016-10-30 13:35:54	0|aj|goatpig: if you have only SW outputs, you're not paying to a legacy output by definition?
 26 2016-10-30 13:36:11	0|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
 27 2016-10-30 13:36:35	0|jl2012|goatpig: you could use native SW as change
 28 2016-10-30 13:36:36	0|goatpig|aj: if someone requests a payment to a plain P2PKJ
 29 2016-10-30 13:36:39	0|goatpig|P2PKH*
 30 2016-10-30 13:36:44	0|goatpig|and i only have SW outputs
 31 2016-10-30 13:36:55	0|goatpig|jl2012: that's what i want to run with so far
 32 2016-10-30 13:37:17	0|goatpig|if the user wants "soft" SW conversion, send change to native P2WPKH
 33 2016-10-30 13:37:18	0|aj|goatpig: then you're *inputs* (or prevouts) are SW, and one of your outputs is the P2PKH
 34 2016-10-30 13:37:19	0|jl2012|SW outputs could be sent to anything, P2PKH or segwit
 35 2016-10-30 13:37:40	0|goatpig|aj: yes, which is a privacy leak, in the light of jl2012 remarks
 36 2016-10-30 13:37:41	0|aj|oops, "your"
 37 2016-10-30 13:38:33	0|goatpig|jl2012: sure you can, but if your payee requests a legacy P2PKH payment, chances are his wallet isn't SW compliant
 38 2016-10-30 13:38:33	0|jl2012|native SW is a even bigger privacy leak, because there is no address for that
 39 2016-10-30 13:38:40	0|goatpig|and he won't see that payment if you force it to SW on your own
 40 2016-10-30 13:38:41	0|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...
 41 2016-10-30 13:38:57	0|jl2012|goatpig: wallet doesn't verify txs, anyway
 42 2016-10-30 13:39:31	0|jl2012|it's a softfork
 43 2016-10-30 13:39:52	0|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
 44 2016-10-30 13:39:54	0|jl2012|of course they will see it. That's the point of a softfork
 45 2016-10-30 13:40:34	0|jl2012|the wallet should not care what the input is
 46 2016-10-30 13:40:44	0|jl2012|they just care  what the output is
 47 2016-10-30 13:41:15	0|jl2012|the input, for an unupgraded wallet, is anyone-can-spend
 48 2016-10-30 13:42:24	0|goatpig|there's an argument to be made for non upgrade wallets, that they simply won't consider the output as theirs
 49 2016-10-30 13:42:32	0|goatpig|even P2WPKH
 50 2016-10-30 13:43:00	0|goatpig|as for native SW, i thought there was a spec for creating addresses out of those?
 51 2016-10-30 13:43:36	0|jl2012|if the payee gives you a P2PKH address, you must send to P2PKH, not P2WPKH
 52 2016-10-30 13:43:45	0|goatpig|of course
 53 2016-10-30 13:43:52	0|goatpig|if all my outputs however are P2WPKH
 54 2016-10-30 13:43:54	0|jl2012|so what's the problem?
 55 2016-10-30 13:43:57	0|goatpig|that's a privacy leak anyways
 56 2016-10-30 13:44:04	0|jl2012|P2WPKH could pay to P2PKH
 57 2016-10-30 13:44:13	0|goatpig|so taht goes back to using P2WPKH output change as default and the privacy leak
 58 2016-10-30 13:44:37	0|goatpig|wait
 59 2016-10-30 13:44:41	0|goatpig|im confusing a couple things here
 60 2016-10-30 13:44:42	0|goatpig|nvm
 61 2016-10-30 13:44:55	0|goatpig|although that's a bit annoying
 62 2016-10-30 13:45:15	0|goatpig|you'd be downgrading a SW output to a P2PKH change in that scenario
 63 2016-10-30 13:45:30	0|jl2012|that's by design
 64 2016-10-30 13:45:41	0|goatpig|ok
 65 2016-10-30 13:45:53	0|goatpig|what's the status on BIP142?
 66 2016-10-30 13:46:21	0|jl2012|i mean, it's up to your design. Or just let the user chooses
 67 2016-10-30 13:46:39	0|goatpig|more GUI complexity, sweet!
 68 2016-10-30 13:46:49	0|jl2012|expert mode
 69 2016-10-30 13:46:59	0|goatpig|i just hate working pyqt4
 70 2016-10-30 13:48:19	0|goatpig|anyways
 71 2016-10-30 13:48:21	0|jl2012|we have some discussion about the address design, like using BASE32
 72 2016-10-30 13:48:46	0|goatpig|wait so BIP142 isn't approved?
 73 2016-10-30 13:48:58	0|goatpig|and why the sudden change?
 74 2016-10-30 14:03:32	0|jl2012|many people hate BASE58
 75 2016-10-30 14:04:16	0|Victorsueca|is base32 like base58 but without caps?
 76 2016-10-30 14:04:38	0|jl2012|case-insensitive
 77 2016-10-30 14:05:20	0|Victorsueca|but addresses would be longer with base32 rigth?
 78 2016-10-30 14:05:25	0|jl2012|sure
 79 2016-10-30 14:05:25	0|Victorsueca|rigth*
 80 2016-10-30 14:06:09	0|jl2012|should be 17% longer with same amount of data
 81 2016-10-30 14:06:25	0|goatpig|is it gonna be a little flavored to avoid 0 and o? or i guess the case agnostic aspect covers that?
 82 2016-10-30 14:06:54	0|Victorsueca|goatpig: I think base 58 already avoids 0 and O
 83 2016-10-30 14:07:10	0|jl2012|there is some discussion to avoid bad word
 84 2016-10-30 14:07:13	0|goatpig|Victorsueca: it does, im wondering if the base 32 proposal is gonna
 85 2016-10-30 14:07:32	0|jl2012|but anyway, we could only take 4 characters away
 86 2016-10-30 14:08:09	0|Victorsueca|it would be base28 then
 87 2016-10-30 14:08:37	0|jl2012|no, 26 + 10 - 4 = 32
 88 2016-10-30 14:08:46	0|luke-jr|btcdrak: nothing wrong with my DNS seed, so must be on your end?
 89 2016-10-30 14:08:46	0|Victorsueca|ahh it's already counted
 90 2016-10-30 14:09:07	0|jl2012|so the question is which 4
 91 2016-10-30 14:09:26	0|Victorsueca|I would remove 0, O, I and i
 92 2016-10-30 14:09:29	0|jl2012|1-L-I ; 0-O
 93 2016-10-30 14:09:47	0|jl2012|if you remove O, you may keep 0
 94 2016-10-30 14:11:16	0|goatpig|quick question about SW, can i create a SW tx but have all emtpy witness programs?
 95 2016-10-30 14:12:04	0|Victorsueca|goatpig: wouldn't e a segwit transaction at all
 96 2016-10-30 14:12:08	0|Victorsueca|be*
 97 2016-10-30 14:12:27	0|jl2012|you mean something like all inputs are P2PKH?
 98 2016-10-30 14:12:45	0|goatpig|jl2012: yup
 99 2016-10-30 14:12:51	0|goatpig|with with the marker and flag
100 2016-10-30 14:12:56	0|jl2012|you must serialize it in the old way
101 2016-10-30 14:13:01	0|goatpig|ok
102 2016-10-30 14:14:23	0|jl2012|goatpig: this is a checklist for everything you need to do as wallet dev https://bitcoincore.org/en/segwit_wallet_dev/
103 2016-10-30 14:15:24	0|btcdrak|luke-jr: is is not accessible from 3 geolocations I tried.
104 2016-10-30 14:16:43	0|goatpig|jl2012: ive seen that but didnt go over it. thanks
105 2016-10-30 14:17:24	0|jl2012|feel free to ask for clarification
106 2016-10-30 14:20:39	0|goatpig|once i get the signer out of the way ill be back with more i expect
107 2016-10-30 14:20:56	0|goatpig|thanks for the help =)
108 2016-10-30 14:58:16	0|Victorsueca|does bitcoin core support 64-bit POSIX time?
109 2016-10-30 16:08:20	0|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?
110 2016-10-30 16:10:13	0|GitHub141|[13bitcoin] 15MarcoFalke opened pull request #9042: [rpc] ParseHash: Fail when length is not 64 (06master...06Mf1611-rpcParseHash64) 02https://github.com/bitcoin/bitcoin/pull/9042
111 2016-10-30 17:27:59	0|GitHub107|[13bitcoin] 15MarcoFalke opened pull request #9043: [qt] Return useful error message on ATMP failure (06master...06Mf1611-qtATMPerror) 02https://github.com/bitcoin/bitcoin/pull/9043
112 2016-10-30 17:32:24	0|luke-jr|btcdrak: well, others seem to hit it fine
113 2016-10-30 17:32:35	0|sipa|tonikt: no
114 2016-10-30 17:32:41	0|luke-jr|Victorsueca: kinda has to, to work on x86_64 Linux
115 2016-10-30 17:33:17	0|luke-jr|sipa: hmm, I understand why that is, but maybe it's going to make life hard for Wireshark >_<
116 2016-10-30 17:34:16	0|sipa|luke-jr: well thankfully the data inside is very similar
117 2016-10-30 17:34:48	0|sipa|2 uses wtxid and can contains witnesses in transactions
118 2016-10-30 17:34:57	0|sipa|1 uses txid and can't
119 2016-10-30 17:35:48	0|luke-jr|yes, but maybe something to keep in mind for future versions
120 2016-10-30 17:36:30	0|sipa|agree
121 2016-10-30 18:25:39	0|GitHub139|[13bitcoin] 15paveljanik closed pull request #8468: Do not shadow member variables in serialization (06master...0620160805_Wshadow_serialization) 02https://github.com/bitcoin/bitcoin/pull/8468
122 2016-10-30 18:52:36	0|petertodd|sipa: ah cool, I was having problems with 100% cpu usage; my vps provider kept turning the seed node off
123 2016-10-30 21:49:27	0|midnightmagic|hah, hilarious: <sipa>    wow, mtgox almost reached $0.5
124 2016-10-30 21:49:29	0|midnightmagic|oldschool
125 2016-10-30 21:50:22	0|sipa|date?
126 2016-10-30 22:05:08	0|Lightsword|hmm, anyone seeing a bunch of spy nodes from AWS? I’m seeing a pattern of 3 connections per IP to my node
127 2016-10-30 22:05:24	0|BlueMatt|thoughts on https://github.com/TheBlueMatt/bitcoin/commit/fe1dc62cef88280d2490a619beded052f313c6fc ?
128 2016-10-30 22:05:52	0|BlueMatt|lightningbot: 3 connections seems low...theres been a bunch of deanonymisation services doing like 10/30 per IP from aws
129 2016-10-30 22:05:52	0|lightningbot|BlueMatt: Error: "3" is not a valid command.
130 2016-10-30 22:05:59	0|BlueMatt|ehh, Lightsword
131 2016-10-30 22:06:14	0|Lightsword|BlueMatt, 3 connections per IP, but many sets of 3
132 2016-10-30 22:06:27	0|BlueMatt|yea, thats some deanonmization attack services
133 2016-10-30 22:06:59	0|Lightsword|BlueMatt, yeah and it’s bitcoinj which normally gets kicked since I block bloom filters
134 2016-10-30 22:07:22	0|BlueMatt|its obviously bullshit bitcoinj, because they claim to be actual wallets (multibit, etc) but dont send bloom filters :p
135 2016-10-30 22:07:36	0|BlueMatt|i mean, yes, probably based on bitcoinj, but obviously not real wallets
136 2016-10-30 22:07:44	0|sipa|BlueMatt: looks good. no need to do hashing in the message processing thread
137 2016-10-30 22:07:51	0|Lightsword|BlueMatt, yep, there a good way to filter those out?
138 2016-10-30 22:08:09	0|BlueMatt|Lightsword: ban them? run a script to ban anything that looks like /bitcoinj :p
139 2016-10-30 22:09:20	0|BlueMatt|sipa: ok, pr'd
140 2016-10-30 22:09:31	0|GitHub178|[13bitcoin] 15TheBlueMatt opened pull request #9045: Hash P2P messages as they are received instead of at process-time (06master...062016-10-p2p-hash) 02https://github.com/bitcoin/bitcoin/pull/9045
141 2016-10-30 22:12:31	0|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?
142 2016-10-30 22:12:35	0|sipa|BlueMatt: i'm a bit surprised we weren't doing that already, actually :)
143 2016-10-30 22:12:43	0|BlueMatt|sipa: i was as well
144 2016-10-30 22:12:56	0|BlueMatt|Lightsword: well at least it'll fix it temporarily :p
145 2016-10-30 22:13:21	0|BlueMatt|Lightsword: you could hack your shit up to request a recent block on connection and ban if they dont respond?
146 2016-10-30 22:19:42	0|gmaxwell|Lightsword: I put up a ban list previously.
147 2016-10-30 22:20:00	0|gmaxwell|http://0bin.net/paste/V0GAccklhV+huNVC#8uKrkZB0NYEHakf+GEf6Bz7995wvwjpYiYddPzAU71e
148 2016-10-30 22:22:31	0|Lightsword|gmaxwell, thanks, think that got most of them
149 2016-10-30 22:23:42	0|gmaxwell|128.101.34.77 is another I've seen more recently.
150 2016-10-30 22:24:16	0|sipa|gmaxwell: university of minnesota?
151 2016-10-30 22:25:46	0|Lightsword|any idea why they open 3 connections per IP?
152 2016-10-30 22:26:18	0|gmaxwell|they're trying to bypass the relay privacy protections.
153 2016-10-30 22:26:36	0|gmaxwell|right now we leak somewhat more information if you make more connections.
154 2016-10-30 22:27:02	0|gmaxwell|We should fix that.  (I knew that when I put in the currency scheme, but it was better than what we had)
155 2016-10-30 22:34:14	0|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?
156 2016-10-30 22:51:31	0|Victorsueca|Lightsword: I just banned the whole 52.0.0.0/8 space
157 2016-10-30 22:51:47	0|Victorsueca|that will get you rid of most of them
158 2016-10-30 22:59:28	0|TD-Linux|that's effectively all of aws, clearly not a very sustainable solution
159 2016-10-30 23:05:12	0|sipa|only 45% of AWE
160 2016-10-30 23:05:21	0|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.
161 2016-10-30 23:05:23	0|sipa|only 45% of AWS's IPv4 space is under 54/*
162 2016-10-30 23:05:32	0|tulip|s/rightward/lightsword
163 2016-10-30 23:05:33	0|sipa|oh, 52
164 2016-10-30 23:06:13	0|sipa|36% is under 52/*
165 2016-10-30 23:07:38	0|BlueMatt|argh, whens the next block :(
166 2016-10-30 23:08:37	0|tulip|BlueMatt: 10 minutes time.
167 2016-10-30 23:11:52	0|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.
168 2016-10-30 23:12:32	0|BlueMatt|well the obvious solution is to fix the bug they're exploiting
169 2016-10-30 23:12:47	0|BlueMatt|if there is no gain from them connecting 10x to each node then hopefully they will go away
170 2016-10-30 23:13:43	0|sipa|is there a reason to assume that hosts in multiple netgroups are harder to obtain than individual ips?
171 2016-10-30 23:14:07	0|BlueMatt|not harder, just more effort and maybe 1.5x cost
172 2016-10-30 23:14:12	0|BlueMatt|well, not hard
173 2016-10-30 23:14:20	0|BlueMatt|tiny bit more effort, not a ton, though
174 2016-10-30 23:14:29	0|sipa|s/harder/costlier/
175 2016-10-30 23:15:02	0|BlueMatt|usually a host will sell you extra ips for reasonably cheap compared to another host somewhere else
176 2016-10-30 23:15:16	0|BlueMatt|but a host that is just proxying traffic is also dirt cheap
177 2016-10-30 23:16:08	0|sipa|otherwise an easy solution would be to use deterministic randomness for the inv push events based on netgroup
178 2016-10-30 23:16:28	0|sipa|so nodes within the same netgroup will see correlated sends
179 2016-10-30 23:17:05	0|BlueMatt|bucketed-announces to most peers is probably the way to go?
180 2016-10-30 23:17:35	0|BlueMatt|it has plenty of issues itself, but at least it solves this specific problem
181 2016-10-30 23:18:49	0|sipa|what do you mean?
182 2016-10-30 23:20:17	0|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
183 2016-10-30 23:22:38	0|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
184 2016-10-30 23:23:32	0|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.
185 2016-10-30 23:24:28	0|BlueMatt|heh, cool
186 2016-10-30 23:27:52	0|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.
187 2016-10-30 23:28:32	0|BlueMatt|I'm sure it cant be too much more expensive
188 2016-10-30 23:28:43	0|BlueMatt|aws is stupid expensive