1 2019-03-08T00:00:16  <promag> sipa: looks like it's related to my changes
  2 2019-03-08T00:01:33  *** timothy has quit IRC
  3 2019-03-08T00:38:34  *** elichai2 has quit IRC
  4 2019-03-08T00:52:47  *** jarthur has quit IRC
  5 2019-03-08T00:53:20  *** bitcoin-git has joined #bitcoin-core-dev
  6 2019-03-08T00:53:20  <bitcoin-git> [bitcoin] Empact closed pull request #15556:  build: Optionally enable -Wthread-safety-attributes (master...wthread-safety-attributes) https://github.com/bitcoin/bitcoin/pull/15556
  7 2019-03-08T00:53:21  *** bitcoin-git has left #bitcoin-core-dev
  8 2019-03-08T00:56:32  *** dviola has joined #bitcoin-core-dev
  9 2019-03-08T00:56:45  *** elichai2 has joined #bitcoin-core-dev
 10 2019-03-08T00:58:29  <phantomcircuit> gmaxwell, i did, the only place that was ok was digital ocean and only once i had gotten explained it to higher level support
 11 2019-03-08T01:04:31  *** DeanGuss has quit IRC
 12 2019-03-08T01:06:18  *** jarthur has joined #bitcoin-core-dev
 13 2019-03-08T01:09:38  *** tryphe has quit IRC
 14 2019-03-08T01:10:11  *** tryphe has joined #bitcoin-core-dev
 15 2019-03-08T01:11:13  *** captjakk has quit IRC
 16 2019-03-08T01:12:19  *** jarthur has quit IRC
 17 2019-03-08T01:12:44  *** captjakk has joined #bitcoin-core-dev
 18 2019-03-08T01:13:19  *** captjakk has joined #bitcoin-core-dev
 19 2019-03-08T01:17:44  *** zhangzf has joined #bitcoin-core-dev
 20 2019-03-08T01:18:57  *** promag has quit IRC
 21 2019-03-08T01:24:52  *** fanquake has joined #bitcoin-core-dev
 22 2019-03-08T01:43:02  <echeveria> phantomcircuit: I had the instance limit on my DO account raised to an absurd level with a one sentence ticket "I WANT TO SCRAPE THE INTERNET". not a very high bar.
 23 2019-03-08T01:47:01  *** jarthur has joined #bitcoin-core-dev
 24 2019-03-08T01:47:48  *** captjakk has quit IRC
 25 2019-03-08T01:48:50  *** jarthur has quit IRC
 26 2019-03-08T02:09:23  *** tryphe has quit IRC
 27 2019-03-08T02:09:51  *** tryphe has joined #bitcoin-core-dev
 28 2019-03-08T02:35:10  *** dviola has quit IRC
 29 2019-03-08T02:51:34  *** schmidty has quit IRC
 30 2019-03-08T02:54:29  *** schmidty has joined #bitcoin-core-dev
 31 2019-03-08T02:58:45  *** schmidty has quit IRC
 32 2019-03-08T03:03:22  *** Aaronvan_ has quit IRC
 33 2019-03-08T03:06:49  *** schmidty has joined #bitcoin-core-dev
 34 2019-03-08T03:09:23  *** tryphe has quit IRC
 35 2019-03-08T03:09:51  *** tryphe has joined #bitcoin-core-dev
 36 2019-03-08T03:11:24  *** schmidty has quit IRC
 37 2019-03-08T03:19:35  *** promag has joined #bitcoin-core-dev
 38 2019-03-08T03:23:47  *** promag has quit IRC
 39 2019-03-08T03:28:19  *** schmidty has joined #bitcoin-core-dev
 40 2019-03-08T03:28:34  *** elichai2 has quit IRC
 41 2019-03-08T03:32:51  *** schmidty has quit IRC
 42 2019-03-08T03:36:58  *** schmidty has joined #bitcoin-core-dev
 43 2019-03-08T03:41:46  *** schmidty has quit IRC
 44 2019-03-08T03:45:05  *** schmidty has joined #bitcoin-core-dev
 45 2019-03-08T03:49:37  *** schmidty has quit IRC
 46 2019-03-08T04:04:34  *** captjakk has joined #bitcoin-core-dev
 47 2019-03-08T04:08:44  *** captjakk has quit IRC
 48 2019-03-08T04:11:24  *** schmidty has joined #bitcoin-core-dev
 49 2019-03-08T04:15:58  *** schmidty has quit IRC
 50 2019-03-08T04:22:16  *** mn949588 has quit IRC
 51 2019-03-08T04:22:31  *** mn949588 has joined #bitcoin-core-dev
 52 2019-03-08T04:26:04  *** spinza has quit IRC
 53 2019-03-08T04:30:07  <shesek> gmaxwell: thanks for the answer. in your opinion, is UIH silly to the point its not worth mentioning as part of a privacy analysis for transactions? and is the preference to spend more inputs when fees are low something that's implemented today?
 54 2019-03-08T04:30:32  *** bitcoin-git has joined #bitcoin-core-dev
 55 2019-03-08T04:30:32  <bitcoin-git> [bitcoin] fanquake opened pull request #15559: doc: correct analysepsbt rpc doc (master...fixup-analysepsbt-rpc-doc) https://github.com/bitcoin/bitcoin/pull/15559
 56 2019-03-08T04:30:33  *** bitcoin-git has left #bitcoin-core-dev
 57 2019-03-08T04:31:47  *** spinza has joined #bitcoin-core-dev
 58 2019-03-08T04:39:09  <gmaxwell> shesek: yes, bitcoin core will spend inputs a bit more when fees are low, though right now that behavior is kinda weak
 59 2019-03-08T04:39:39  <gmaxwell> as in it only does it as part of the branch and bound analysis for changeless spends.
 60 2019-03-08T04:39:52  <gmaxwell> (that isn't the only case where it can spend extra inputs)
 61 2019-03-08T04:41:04  <gmaxwell> I just don't really understand the motivation of it as a privacy hurestic.   extra inputs could both help (e.g. spend all inputs connected to a given script pubkey, make change amount and payment amount harder to tell apart) or harmful to privacy (link otherwise unlinked scriptpubkeys, make change more distinguisahble)
 62 2019-03-08T04:41:20  <gmaxwell> depending on the specific case.
 63 2019-03-08T04:53:58  *** gxd has joined #bitcoin-core-dev
 64 2019-03-08T04:54:39  <gxd> hello everyone!
 65 2019-03-08T04:55:06  <gxd> nNce to meet you!
 66 2019-03-08T04:55:45  *** gxd has quit IRC
 67 2019-03-08T05:12:58  <shesek> gmaxwell: the motivation is to give users and developers some better indication of potential privacy gotchas they might need to pay attention to. I understand, for example, that making p2ep/payjoin not trigger UIH-2 to make it blend in better with transactions produced by consumer wallets is something they're explicitly aiming for
 68 2019-03-08T05:15:35  <shesek> if more wallets implemented coin selection algorithms that sometimes trigger UIH rather than aiming to minimize short-term fees, this heuristic would eventually become useless. but it seems that as things stand today, triggering UIH-2 does reduce your anonymity set, making it a useful analysis technique
 69 2019-03-08T05:16:26  <shesek> the context, if this wasn't clear, is the privacy-related notices added to esplora, for example on: https://blockstream.info/tx/38af11480de5129726c66207db9eb8cb0be0ff0f8b1ac6f569315d9444787563
 70 2019-03-08T05:16:36  *** echeveria has quit IRC
 71 2019-03-08T05:16:42  <gmaxwell> shesek: IIRC bitcoin core has always violated it from day one. just not that all that often.
 72 2019-03-08T05:16:56  <sipa> i believe that's correct
 73 2019-03-08T05:16:56  *** echeveria has joined #bitcoin-core-dev
 74 2019-03-08T05:16:56  *** echeveria has joined #bitcoin-core-dev
 75 2019-03-08T05:17:31  *** echeveria has joined #bitcoin-core-dev
 76 2019-03-08T05:17:31  *** echeveria has joined #bitcoin-core-dev
 77 2019-03-08T05:18:01  <shesek> the preference to spend all utxos belonging to the same scriptpubkey in one go could be accounted for by opting transactions with multiple inputs of the same scriptpubkey out of UIH detection
 78 2019-03-08T05:18:40  <shesek> this leaves UIH due to MIN_CHANGE and low fees period? are there more potential causes?
 79 2019-03-08T05:20:35  *** hebasto has joined #bitcoin-core-dev
 80 2019-03-08T05:27:34  <gmaxwell> shesek: yes, coin selection can just pick extra inputs.
 81 2019-03-08T05:27:41  <gmaxwell> because the algorithim is probablistic.
 82 2019-03-08T05:33:18  <shesek> it would be interesting to test a bunch of transactions produced by bitcoin core and see what percent of them matches UIH-2. but I'm not using core to produce transactions, any thoughts on where one might be able to find a list of txids that are known to be core-originated?
 83 2019-03-08T05:34:38  <shesek> what does your intuition tell you? would you expect them to be common? say, more common than 2%?
 84 2019-03-08T05:35:14  <shesek> (assuming spending all utxos of the same address is accounted for and not considered as uih)
 85 2019-03-08T05:35:55  <gmaxwell> I expect it depends a lot on the wallet's composiion. if the wallet has a lot of really tiny inputs that are smaller than the payment amount then it's much more likely.
 86 2019-03-08T05:36:41  <gmaxwell> I'd be surprised if it happened more than a few percent of the time except w/ pathlogical wallets
 87 2019-03-08T05:36:53  <gmaxwell> oh well minchange makes it happen pretty often too
 88 2019-03-08T05:37:02  <shesek> so not so common on a typical wallet that receives payments about the same size as he sends
 89 2019-03-08T05:37:49  <shesek> minchange would also mostly kick into action with lots of tinyish inputs though, right?
 90 2019-03-08T05:38:25  <shesek> s/sends$/sends?/ (was meant as a question)
 91 2019-03-08T05:39:21  <gmaxwell> lots of small inputs is much more likely to find an exact (changeless) solution via branch and bound.
 92 2019-03-08T05:43:50  *** justanotheruser has quit IRC
 93 2019-03-08T05:48:18  <shesek> hmm, this brings up another heuristic I've been wondering about: change-less transactions as an indicator that he bitcoins possibly didn't change hands (by a user using "send max" to move to a new wallet, for depositing to an exchange, opening a lightning channel, etc). I'm aware that sophisticated coin selection algorithms attempt to avoid change if possible, but it still seems like it would require some non-negligible amount of luck and
 94 2019-03-08T05:48:18  <shesek> wouldn't be all that common, except perhaps for places like casinos that have *lots* of very small inputs. my intuition is telling me that using "send max" or doing manual coin selection for exact self-transfers (like from cold to hot, where an advanced user might pick some specific utxos by hand and send them in full) would be far more common than the coin-selection algorithm being smart/lucky enough to be able to avoid change
 95 2019-03-08T05:48:27  <gmaxwell> I'm working updating my blocklists, if anyone would like to send me connection info from your ipv4 publically reachable nodes, it would be helpful:
 96 2019-03-08T05:48:29  <gmaxwell> ./bitcoin-cli getpeerinfo | grep '^    "addr"'  | grep '[0-9]\.' | cut -d'"' -f4 | cut -d':' -f1  | sort | uniq
 97 2019-03-08T05:49:01  <shesek> but my intuition might be broken :) what do you think? is this a reasonable heuristic to point out?
 98 2019-03-08T05:49:12  <gmaxwell> shesek: bitcoin core manages to produce changeless payments quite often, so long as the wallet has many inputs.
 99 2019-03-08T05:51:27  *** DeanGuss has joined #bitcoin-core-dev
100 2019-03-08T05:52:46  <shesek> what would you consider as many? thousands? hundreds? or even just a few dozens?
101 2019-03-08T05:52:51  <gmaxwell> shesek: it's much more likely than you think... it doesn't have to be exact because it can overpay by the amount of future fees it would use to spend the change, also can overpay by the fees it would spend to create a change output. if the number of inputs much smaller than the payment amount is larger than the number of bits in the amount, minus the number of bits in the amount it can overpay
102 2019-03-08T05:52:51  <gmaxwell> fees by, then there is probably a changeless solution, and bitcoin core will find it if there is one.
103 2019-03-08T05:52:58  <gmaxwell> dozens works.
104 2019-03-08T05:53:20  <sipa> it's much easier to find a changeless input selection when the feerate is high
105 2019-03-08T05:53:54  <gmaxwell> I've seen it find changeless soluions in my own walle, which doesn' have that many inputs.
106 2019-03-08T05:54:59  <shesek> I looked through my electrum history, couldn't spot a single changeless transaction except for manual coin selection ones
107 2019-03-08T05:55:33  <sipa> i doubt electrum has bab
108 2019-03-08T05:55:39  <gmaxwell> Weakling wallet software. :P
109 2019-03-08T05:55:48  <gmaxwell> Lacks advanced science power.
110 2019-03-08T05:55:49  <gmaxwell> :P
111 2019-03-08T05:56:37  <shesek> bitcoin core seems pretty smart about this. but, unfortunately, I don't think its actually being used to produce that many transactions, or does it? are there any estimates on that?
112 2019-03-08T05:57:12  <gmaxwell> shesek: pretty significant fraction of all, at least a year ago it was many times more than electrum.
113 2019-03-08T05:57:36  <gmaxwell> electrum gets used by a lot of small indivigual users that don't transact frequenly...
114 2019-03-08T05:58:49  <shesek> oh really. interesting. I would've expected it to be dominated by custom software made for commercial usage by exchanges/mining pools/etc. even just 4-5 of the big exchanges using some custom software and it should easily be a majority of txs
115 2019-03-08T06:04:02  <shesek> so I'll do some more thinking and reconsider the privacy analysis regarding UIH and changeless transactions. maybe remove, maybe change the wording/colors. thank you greg and sipa for your time and feedback. if you have any other thoughts on what esplora should display regarding privacy (some other interesting heuristics I missed?), please do let me know :)
116 2019-03-08T06:04:59  *** hebasto has quit IRC
117 2019-03-08T06:06:39  <shesek> the ones I currently have is address reuse, round payment amounts, sending change to a different script type than the payment, UIH1/UIH2, and changeless transactions
118 2019-03-08T06:07:48  <shesek> and a (very naive) heuristic to find transactions that look like equal-output coinjoin and display a positive badge next to them :)
119 2019-03-08T06:08:58  <gmaxwell> Address reuse, 'round payments amounts', mixed output types have obvious privacy implications to me, that rest I still don't see how they relate to privacy.
120 2019-03-08T06:09:44  <gmaxwell> how does the output type thing handle > 2 outputs?
121 2019-03-08T06:12:36  *** schmidty has joined #bitcoin-core-dev
122 2019-03-08T06:13:35  <shesek> it currently doesn't attempt to, its only applied to transactions with exactly two outputs
123 2019-03-08T06:14:06  <gmaxwell> does it pay attention to input types at all for that?
124 2019-03-08T06:15:11  <gmaxwell> also does it treat all p2sh as equal typed?
125 2019-03-08T06:15:52  <shesek> it does. it checks that one output is of a script type that doesn't match any of the input's previous output's script type, while the other output does match at least one
126 2019-03-08T06:15:52  <gmaxwell> eventually p2sh will be spent and you'll know the type... so what would have looked the same before often will look different later.
127 2019-03-08T06:16:47  <shesek> p2sh is considered equal. I thought about looking for spends to find the preimage script, but didn't get into that for now
128 2019-03-08T06:16:50  *** schmidty has quit IRC
129 2019-03-08T06:16:56  <gmaxwell> that hurestic will pretty reliably misidentify change for many bitcoin core users right now. :)
130 2019-03-08T06:17:31  <shesek> oh really. how so?
131 2019-03-08T06:17:57  <gmaxwell> because many users have non-sw inputs, but then make a payment to a 1x address, and end up with a native sw change (in that case), ... the 1xx output is not their change. :P
132 2019-03-08T06:18:29  <gmaxwell> core will match change type for p2sh vs native, but not legacy (unless overridden).
133 2019-03-08T06:18:38  <shesek> ah, I see, interesting
134 2019-03-08T06:19:35  <shesek> I didn't know core can be configured to match its change for payments to legacy scripts, very cool!
135 2019-03-08T06:19:42  <gmaxwell> electrum made some odd decisions with segwit deployment, e.g. forcing wallets to be native segwit or not segwit
136 2019-03-08T06:19:51  *** promag has joined #bitcoin-core-dev
137 2019-03-08T06:20:24  <kallewoof> gmaxwell: I can send IP info from public node. How would you like it sent tho?
138 2019-03-08T06:20:54  <gmaxwell> kallewoof: 0bin and an irc private message would be preferred.  or an email.
139 2019-03-08T06:23:43  <kallewoof> sent
140 2019-03-08T06:24:10  *** promag has quit IRC
141 2019-03-08T06:24:37  <gmaxwell> kallewoof: thanks!
142 2019-03-08T06:31:33  <shesek> gmaxwell, change-less transactions due to finding a suitable set of inputs would normally have quite a few inputs, right? do you think it would be more useful if I only applied this heuristic to transactions of less than, say, 5 inputs?
143 2019-03-08T06:32:45  <shesek> 1-2 inputs, 1 output transactions are quite common, and are very unlikely to be a suitable set of inputs for the intended payment amount
144 2019-03-08T06:33:34  <shesek> I can't see any way to parse a 1 in, 1 out transaction other than a self-transfer that didn't change ownership, can you?
145 2019-03-08T06:33:35  <gmaxwell> shesek: what matters more is how many inputs it has to choose from, not how many get used.
146 2019-03-08T06:34:04  <shesek> how many got used is also important, no? more inputs allows you more combinations
147 2019-03-08T06:34:21  <shesek> finding a combination of two utxos that matches the payment amount is harder than finding a combination of 4
148 2019-03-08T06:36:54  <gmaxwell> Yes, it's easier to find exact maches when there are more inputs. But e.g. 60 choose 3 already gives you more than 34 thousand possible combinations.
149 2019-03-08T06:37:30  <gmaxwell> on change ownership, 1-to-1 probably isn't a payment, but would often be paying into a users account at an exchange with a shared wallet.
150 2019-03-08T06:37:53  <gmaxwell> which for taint analysis sorts of purposes is just a payment.
151 2019-03-08T06:39:11  <shesek> right, I'm lumping this as "didn't change ownership" (it technically did, from the user to the exchange under the user account, but its still "his"). the idea being that you normally care about the exact amount you're sending, unless you're sending this to yourself (or to someplace you believe/expect to be under your control in some way)
152 2019-03-08T06:40:10  <shesek> I would still consider this leakage of private information, even if it moved to a different wallet and not so useful for taint analysis
153 2019-03-08T06:41:15  <gmaxwell> How?  if you rewrite an address on a single txout from one address to another what information did you leak?  maybe that your computer was online at the time? -- but thats inherent to making any kind of transaction.
154 2019-03-08T06:41:50  <gmaxwell> Again, it sounds like you're basically writing detect bitcoin core and print nasty warnings about litterly the only widely used wallet software that provides users with a decent degree of privacy at all.
155 2019-03-08T06:44:38  <shesek> well, I'm open to listening and trying to find ways to improve it :)
156 2019-03-08T06:44:59  *** d_t has quit IRC
157 2019-03-08T06:45:12  *** d_t has joined #bitcoin-core-dev
158 2019-03-08T06:45:15  <gmaxwell> Well I keep saying that I don't see how these things are releated to privacy and I'm still not hearing a response.
159 2019-03-08T06:46:05  <shesek> gmaxwell, if it was to an address that was later known to be associated with an exchange, it would leak that you likely sold your bitcoins, rather than sent funds to someone else's exchange deposit address
160 2019-03-08T06:47:08  <shesek> another common case for no change is moving to a new wallet or selling off fork coins using "send max", which has obvious privacy implications
161 2019-03-08T06:47:33  *** zhangzf has quit IRC
162 2019-03-08T06:47:46  <gmaxwell> There is no 'send max' in many wallets.
163 2019-03-08T06:47:53  <sipa> shesek: in the 1-input 1-output case it seems indeed more likely than not that no change of ownership was involved
164 2019-03-08T06:47:58  <shesek> UIH-1 is pretty effective at detecting the change output of transactions produced by wallets that minimize immediate fees without much long-term thought or smart coin selection
165 2019-03-08T06:48:09  *** zhangzf has joined #bitcoin-core-dev
166 2019-03-08T06:48:11  <sipa> but if we're talking about multiple inputs... not so much
167 2019-03-08T06:48:26  <shesek> UIH-2 is pretty effective at detecting that a transaction was not produced by a short-term-fee-minimizing wallet software
168 2019-03-08T06:48:33  <gmaxwell> It's the absense of alternative explinations that make an action identifyable, not the presence of a single articulable cause.
169 2019-03-08T06:48:34  *** hamma has joined #bitcoin-core-dev
170 2019-03-08T06:49:12  <hamma> hello
171 2019-03-08T06:49:19  <gmaxwell> shesek: FWIW 20% of the donations to me that I see are 1-in-1-out.
172 2019-03-08T06:49:38  <hamma> anyone here
173 2019-03-08T06:50:07  <gmaxwell> (maybe people emptying out wallets? dunno.)
174 2019-03-08T06:50:08  <shesek> right, donations made by expert users that do manual coin selection is another potential reason. I was just writing that down in the wiki Privacy page today :) https://en.bitcoin.it/w/index.php?title=Privacy&diff=66261&oldid=66255
175 2019-03-08T06:51:48  <gmaxwell> so that page at the top recommends to improve privacy users should "Try to avoid creating change addresses" ... but then you want to display a warning for privacy loss when they do? :P
176 2019-03-08T06:52:17  *** hamma has quit IRC
177 2019-03-08T06:54:13  *** harding has quit IRC
178 2019-03-08T06:54:45  <shesek> well, I display a warning that it seems like it might be a self-transfer. if they know that this was a payment and not a self-transfer, they'll know there's nothing to worry about. but if they just emptied their old wallet into the new one by using "send max", it'll give them a warning that could help them learn for the next time they do this
179 2019-03-08T06:55:25  <shesek> sipa, I think that you still have some pretty high likelihood even with 2-3 inputs, especially if you consider wallet software that's not as sophisticated as core
180 2019-03-08T06:55:53  <echeveria> I really caution against doing things like that. people will treat the absence of warnings as a sign of safety, which we know not to be true.
181 2019-03-08T06:56:04  <shesek> I would really love to run an analysis and get some numbers >_<
182 2019-03-08T06:56:15  <gmaxwell> shesek: so what happens if there are other outputs to the same spks that are spent from? clearly that wasn't a "send max".
183 2019-03-08T06:56:37  <shesek> echeveria, the message shown when there's nothing to show is "his transaction doesn't violate any of the privacy gotchas we cover. Read on other potential ways it might leak privacy.", with a link to https://en.bitcoin.it/wiki/Privacy#Blockchain_attacks_on_privacy
184 2019-03-08T06:56:51  <gmaxwell> shesek: actually thats something you could note? incomplete spend.  E.g. if there are more unspent outputs to the same scripts being spent which weren't spent.
185 2019-03-08T06:58:02  <shesek> yes, I definitely could, and turn off the "possibly self-transfer" message when that happens.
186 2019-03-08T06:58:31  <gmaxwell> any incomplete spend ultimately hurts privacy, because its one of the main causes of taint snowballing.
187 2019-03-08T06:58:51  <shesek> ah, I see, so an explicit message about not spending all available utxos in one go... yes, definitely :)
188 2019-03-08T06:59:09  <shesek> noted!
189 2019-03-08T06:59:46  <echeveria> shesek: my comment stands, really. just by seeing the message they leaked their own privacy.
190 2019-03-08T07:00:28  <shesek> by visiting a public block explorer you mean?
191 2019-03-08T07:00:40  <gmaxwell> I agree that electrum's "send max" is privacy hurting, but changeless isn't an especially strong hurestic to detect it unfortunately.
192 2019-03-08T07:00:52  <echeveria> shesek: the best block explorer is a search box that tells you you're a moron as soon as you click in a box labeled "enter TXID".
193 2019-03-08T07:00:57  <sipa> of course, the most important thing to put on a blockexplorer is "Warning: looking up your own addresses on a blockexplorer leaks your privacy to the site operator"
194 2019-03-08T07:01:11  <shesek> echeveria, well, esplora is open-source, you could self-host it :)
195 2019-03-08T07:01:11  <gmaxwell> yea, use of the explorer (or electrum in the first place) is a bigger privacy loss than "send max".
196 2019-03-08T07:01:12  *** harding has joined #bitcoin-core-dev
197 2019-03-08T07:01:45  <shesek> gmaxwell, its not just "send max" though, its also users doing manual coin selection for transfers between their own wallets
198 2019-03-08T07:02:01  <gmaxwell> just always display "privacy note: this address has been looked up on a public explorer" :P
199 2019-03-08T07:02:02  <shesek> I've done this countless times
200 2019-03-08T07:02:08  <sipa> shesek: sure, just don't include the warning in the open source version :)
201 2019-03-08T07:02:27  <gmaxwell> just have a config flag, "public_explorer=1"
202 2019-03-08T07:02:29  <gmaxwell> :P
203 2019-03-08T07:02:58  <gmaxwell> shesek: sure but my point above remains: its not the existance of a pattern that makes something a privacy loss, its the absense of alternative explinations.
204 2019-03-08T07:03:57  <shesek> gmaxwell, no way, "send max" for a wallet with hundreds or even dozens of transactions is probably the worse thing one could do, much worse than using an explorer
205 2019-03-08T07:04:17  <sipa> shesek: you can't compars those things
206 2019-03-08T07:04:27  <shesek> this is especially common around forkcoins selloffs
207 2019-03-08T07:04:38  <gmaxwell> shesek: if you run electrum at all (e.g. have that send max button) then EVERY time your start it, the software is connecting to random hosts on the internet and sending your complete address list to them.
208 2019-03-08T07:04:53  <gmaxwell> it's more or less a total privacy loss.
209 2019-03-08T07:04:56  <shesek> I'm running electrum with EPS and oneserver :)
210 2019-03-08T07:05:11  <gmaxwell> okay you're weird. but you know that isn't true for more than a tiny percent of users. :)
211 2019-03-08T07:05:33  <shesek> and "send max" is available on nearly all consumer wallets that I know of, its a super useful feature that users are asking for
212 2019-03-08T07:05:42  <shesek> its not just an electrum thing
213 2019-03-08T07:05:48  <gmaxwell> Similarly going and looking up your transactions on most explorers is linking your IP to it, browser tracking cookies etc. And at least some sell the data to third parties.
214 2019-03-08T07:06:15  <echeveria> more than that. just the simple act "someone is interested in this transaction" is insane information.
215 2019-03-08T07:06:25  <sipa> shesek: they're both bad... but you can't compare them; linkage with an IP address is terrible in some cases and more or less harmless in others
216 2019-03-08T07:06:35  <shesek> right, but you'll be linking the few addresses you're looking up at the moment, and the link is just that you looked at them, not that they're yours
217 2019-03-08T07:06:44  <gmaxwell> shesek: and every one of those wallets sends all their addresses to a third party server on start, though some of them its just one server instead of anonymously run internet ones.
218 2019-03-08T07:06:51  <shesek> "send max" links all your wallet addresses together, on a public blockchain, for all ethernity
219 2019-03-08T07:07:08  <sipa> shesek: but maybe they were already clearly linked together for other reasons
220 2019-03-08T07:07:13  <echeveria> doesn't matter. the fact that someone cares at all about a transaction makes it hugely interesting.
221 2019-03-08T07:07:51  <sipa> i am super happy that there is a decent explorer now for debugging stuff out there
222 2019-03-08T07:08:18  <sipa> but i'm concerned about making it sound like it's an actual production tool
223 2019-03-08T07:08:47  <sipa> i know people will use explorers, and one that gives good information is better than one that confuses everything
224 2019-03-08T07:09:00  <shesek> echeveria, it is interesting, but the link is not as strong as when linking addresses together as inputs of a tx. I'm not defending using public block explorers, just saying that there might be some worse things :)
225 2019-03-08T07:09:06  <sipa> but really... we shouldn't encourage using the
226 2019-03-08T07:10:45  <gmaxwell> shesek: an actual sendmax would also spend all inputs that were cojoined siblings from prior spends... and that would essentially never happen from a BNB changeless spend.
227 2019-03-08T07:11:09  <gmaxwell> except when there just wasn't any linked history at all.
228 2019-03-08T07:11:13  <sipa> like... if this privacy detection feature causes people to go look up all their transactions because of a gamification like feeling "oooh let's see how my transaction did here?!", it's probably a net negative...
229 2019-03-08T07:11:43  <sipa> (only talking about widely used public instances here)
230 2019-03-08T07:12:05  <shesek> gmaxwell, sorry, BNB?
231 2019-03-08T07:12:27  <gmaxwell> I'm concerned with it being like the "bitcoin privacy project" which had a bunch of spurrious privacy unrelated ratings that caused it to derate the only options that had remotely good privacy (bitcoin core and armory) and rate over them a dozen wallets that sent all the users addresses to third parties.
232 2019-03-08T07:12:31  <sipa> shesek: branch and bound, the algorithm we use for changeless input selectio
233 2019-03-08T07:13:07  <shesek> ah, okay. and what does cojoined siblings mean?
234 2019-03-08T07:13:47  <shesek> like, outputs of the same transaction?
235 2019-03-08T07:14:22  <shesek> probably not, because a user creating multiple outputs to himself in the same tx is quite unlikely
236 2019-03-08T07:14:33  <gmaxwell> shesek: like if tx1 spends spk A, B, C, D.  and then tx2 spends C, D, E, F  then spks a-f probably belong to one user (absent coinjoins)
237 2019-03-08T07:14:56  <gmaxwell> (and there is a related hurestic that you can do if you identify change, but its far less reliable)
238 2019-03-08T07:15:00  <echeveria> sipa: it's definitely being promoted as "use this tool to evaluate your privacy", which is sort of in line with a "enter your credit card to see if it has been stolen" sort of thing. perhaps not in this case, but for sure something not to be promoted.
239 2019-03-08T07:15:25  <gmaxwell> A send-max will spend any spendable outputs to A-F.
240 2019-03-08T07:15:39  *** rockhouse has joined #bitcoin-core-dev
241 2019-03-08T07:15:42  *** victorSN has joined #bitcoin-core-dev
242 2019-03-08T07:16:05  <gmaxwell> If something spends coins to E, F, G, H   but there are also coins paid to B.. it's almost certantly not a send-max.
243 2019-03-08T07:16:32  <gmaxwell> it might be some kind of manual selection payment or a exact match payment.
244 2019-03-08T07:16:55  <echeveria> if anyone wants data, looking at the thefts from Electrum are good examples. it involves "send max" from around 500 different user wallets from $100 up to $100,000 in various formulations of outputs.
245 2019-03-08T07:16:57  <shesek> echeveria, being promoted by whom? I see this more as a way to reach the attention of people already using the block explorer regardless
246 2019-03-08T07:18:16  <sipa> i do like that the detected patterns are just links to the wiki explaining it, and not just a good/bad rating
247 2019-03-08T07:18:32  <echeveria> shesek: well, literally you. https://twitter.com/Excellion/status/1103614846468161537
248 2019-03-08T07:19:49  <shesek> *literally* me? I'm pretty sure I'm not samson :p
249 2019-03-08T07:20:12  <gmaxwell> shesek: it's quoting you.
250 2019-03-08T07:21:16  <shesek> but also, I'm not seeing him promoting users to go and check their own transactions proactivly to get the ratings, just that it helps improve their privacy (in my view, by giving them this information when they go to the block explorer either way)
251 2019-03-08T07:21:31  <shesek> gmaxwell, but I think he meant specifically the text by samson? my text says even less
252 2019-03-08T07:29:37  <shesek> gmaxwell, do you think that displaying privacy analysis information is a good idea but the heuristics need some adjustments, or is it a misguided effort in your view?
253 2019-03-08T07:30:21  <shesek> I'm getting the feeling you're somewhat negative about all this, genuinely interested in understanding your position
254 2019-03-08T07:30:47  <gmaxwell> I think it's probably useful, but care has to be taken to not give misleading results... and having people going to a public explorer and pumping in their addresses is a really bad pattern, and I'm not sure how to discourage that.
255 2019-03-08T07:31:31  <shesek> the reason I came here asking for questions is exactly that care :)
256 2019-03-08T07:31:32  <echeveria> first and permanent item on the list: you just messed up by ending up on this page.
257 2019-03-08T07:32:21  <midnightmagic> :-/
258 2019-03-08T07:32:32  <shesek> I do want to do this right and am very open to feedback
259 2019-03-08T07:33:21  <gmaxwell> Well I still can't see how the UIH is essentially anything other than bitcoin core (derrived code) detection. And I think that sysematically putting up privacy warnings on the by far most private option (in spite its other costs) is really harmful.
260 2019-03-08T07:34:25  <gmaxwell> shesek: as far as the going and typing in your txn to check your privacy, it could work by only showing the privacy flags on the full block view... but I somewhat doubt that would help because people will still first try to lookup by address/txid.
261 2019-03-08T07:34:58  <gmaxwell> (so my advice there, submit patched to electrum/core/ga to provide the privacy notes :P )
262 2019-03-08T07:36:02  <shesek> UIH 1 or 2? UIH 1 is quite effective with most typical consumer wallet software. and you can check for some fingerprints first to try and rule out bitcoin core transactions (say, fee sniping nlocktime)
263 2019-03-08T07:36:09  <gmaxwell> (and if you want to do a wallet type detection, that seems worthwhile, but it should be that, and not in triggering spurrious privacy warnings)
264 2019-03-08T07:36:24  <gmaxwell> I don't understand how UIH is privacy related at all.
265 2019-03-08T07:36:36  <gmaxwell> I get that its a hurestic that electrum or whatever won't violate.
266 2019-03-08T07:36:39  <shesek> UIH-2 is effective as an heuristic for "produced by core or by some other non typical consumer wallet software"
267 2019-03-08T07:37:52  <shesek> I can understand how it might not be effective, but how come they're not even related?
268 2019-03-08T07:38:30  <sipa> as a neutral message "This transaction matches a pattern that is not common in all wallet software; software this is known to produce this type includes X, Y, Z, ..."
269 2019-03-08T07:38:36  <gmaxwell> if your only interest in it is detecting the wallet software thats fine, but then just show a wallet software estimate.
270 2019-03-08T07:38:45  <gmaxwell> There are much stronger identifers of the wallet software.
271 2019-03-08T07:39:17  <sipa> tx version, anti fee sniping locktimes, low r grinding, ...
272 2019-03-08T07:39:39  <gmaxwell> support for mixed sw and non-sw inputs. ability to pay to varrious output types, multisig...
273 2019-03-08T07:39:40  <shesek> its not necessarily about which wallet it was, just the fact that it was a non-typical-consumer-wallet is useful too
274 2019-03-08T07:39:46  <echeveria> as a historical reminder, this is the sort of thing that blockchain.info had on their site, "taint analysis" which gave a series of important sounding but utterly meaningless pieces of information about a transaction. it was used by themselves and others to sell snake oil, because of course the underlying heuristic was easily disrupted without meaningful change in privacy, or potentially even a decrease.
275 2019-03-08T07:40:10  <gmaxwell> yea, that taint analsis thing was pretty much an rng. :P
276 2019-03-08T07:40:30  <sipa> shesek: i agree that leaking what software you're using is a leak
277 2019-03-08T07:41:10  <gmaxwell> shesek: the end effect is you get some weird privacy warning on a small but non-trivial percentage of bitcoin core txn, ... but how does this help anyone? it just spreads fud. The txn are usually identifyable through other characteristics.
278 2019-03-08T07:41:34  <sipa> but if there is software X which never does A, and software Y which does, but randomly based on unobservable properties of the wallet... you can't say this leaks information about your behavior... just about the software you're using
279 2019-03-08T07:41:51  <gmaxwell> indeed, it's a leak but it's a pretty well defined one, and a really hard to avoid one (esp if everyone isn't suicide packed into never improving)
280 2019-03-08T07:42:11  <sipa> but saying "this transaction is identifiable as being produced by software X" is exactly right
281 2019-03-08T07:42:26  <echeveria> there's a lot more of those than you've mentioned. UTXO selection is a privacy leak, just by the differences in the way wallets do it. there's some BIP proposals which try to define canonical forms for transactions, but manages to be inept in its description to the point it cant be implemented. it means that any wallets that did have yet another bit of definition about what created them, rather than less.
282 2019-03-08T07:42:53  <gmaxwell> So I wouldn't see any issue with giving an estimate of the originating software, --- thats a well defined thing which users should know is usually detectable.
283 2019-03-08T07:43:11  <gmaxwell> But giving little warning dings instead is fuddy.
284 2019-03-08T07:45:05  <gmaxwell> also adding extra inputs itself is good for the network in general, and can be good for privacy if done right. But if this thing is printing a warning on it it'll be harder to get other wallets to do it.
285 2019-03-08T07:45:39  <gmaxwell> which then prolongs it being an identifier, which is bad to whatever extent being identifyable is bad.
286 2019-03-08T07:46:12  <gmaxwell> it also doesn't give a baseline.
287 2019-03-08T07:47:31  <shesek> re "(esp if everyone isn't suicide packed into never improving)" - for a wallet that wants to maximize its anonymity set, it makes sense to use characteristics that are as common as possible, even if its less ideal for other reasons. for example, payjoin are intentionally trying to avoid uih-2 to enjoy a bigger anonymity set. and some of the arguments against bip69 lexicographical ordering were on a similar basis, that wallets that do
288 2019-03-08T07:47:31  <shesek> implement it will stand out in the transition period
289 2019-03-08T07:48:01  *** d_t has quit IRC
290 2019-03-08T07:48:10  <gmaxwell> Imagine that there are three wallets -- A, B, C -- which are utterly indistinguishable but combined add to just 3% of users. Then there is another wallet with 25% of the users, D.  You can't distinguish the software for  A/B/C but you can identify D.   Yet D has a much larger anonymity set.
291 2019-03-08T07:48:10  <shesek> it could perhaps be displayed differently, just as a note rather than a "warning" sort of thing
292 2019-03-08T07:49:12  <shesek> I already did split this up into red and orange messages, where the red ones can be improved by changing user habits or wallet software, and orange are the "we kinda have to leave with them"
293 2019-03-08T07:49:25  <shesek> ugh, live
294 2019-03-08T07:49:27  <gmaxwell> bip69 also just didn't add anything in and of itself, it's not like there was a "this is much better but its inconsistent so don't do it"
295 2019-03-08T07:50:25  <shesek> I could actually just analyze the whole history for UIH-2 and see what % of transactions is matched by it
296 2019-03-08T07:50:34  <shesek> is there a % under which you would consider this a valid heuristic?
297 2019-03-08T07:51:51  <echeveria> shesek: wallets aren't even slightly homogeneous even today. there's so many indicators of what wallet software is being used. did you know that you can fast poll fee-rate APIs and correlate wallet transactions that way? the value of a feerate is typically pretty unique.
298 2019-03-08T07:52:09  <gmaxwell> A valid huristic for what though?   I believe the _only_ information it provides is that the transaction was not produced by one of the pieces of software that will never include additional inputs.  But for most transactions you can already tell that from other factors, so for those transactions it tells you precisely nothing additional.
299 2019-03-08T07:54:36  <shesek> gmaxwell, and if the "pieces of software that will never include additional inputs" account for, say, 85% of transactions on the network, and including additional inputs puts you in a 15% minority, wouldn't that be quite harmful to privacy?
300 2019-03-08T07:55:06  <gmaxwell> no! because other properties of the transaction already identify the source software.
301 2019-03-08T07:56:21  <shesek> echeveria, its not about which wallet it is, more of a boolean "is it a typical immediate-fee-minimizing consumer wallet software" thing. this also helps with analyzing change outputs, as you can follow up on chains and see that some outputs are later spent by non-consumer-wallet software, which gives away this wasn't the change
302 2019-03-08T07:56:41  <gmaxwell> also virtually all consumer wallets have no privacy at all because they phone home their address lists, so it would be really odd to say "this txn has poor privacy because we can detect it coming from one of the only widely used solutions that has any privacy at all"
303 2019-03-08T07:57:36  <shesek> gmaxwell, do you think payjoin should not make an explicit effort to avoid triggering uih-2?
304 2019-03-08T07:57:46  <gmaxwell> shesek: you can already often idetify the wallet from other criteria regardless, nlocktime, rbf, fee levels, the size of signature r values, use of script types, mixture of script types, supported output types.
305 2019-03-08T07:58:27  <shesek> right, and this is one more of these heuristics... for every specific heuristic you look at, one could say "but look at all these other heuristics, why use this one?"
306 2019-03-08T07:58:34  <echeveria> fee rate rounding, output ordering, input ordering, utxo selection criteria.
307 2019-03-08T07:59:19  <echeveria> huh?
308 2019-03-08T07:59:26  <gmaxwell> shesek: I think never breaking UIH-2 probably gives it a smaller anonymity set, though its hard to tell. To make that determination you need to estimate a wallet distribution on the network, and then determine which of them will violate UIH-2 sometimes (but rarely)
309 2019-03-08T08:00:43  <gmaxwell> (and thats ignoring that enforcing UIH-2 would mean that you could just payjoin less often, which is sure to be a privacy loss)
310 2019-03-08T08:01:27  <gmaxwell> And also avoiding UIH-2 normatively would almost certantly be a mistake, since as wallets improve more will violate it.
311 2019-03-08T08:03:12  <gmaxwell> shesek: as far as "why use this one" -- I don't see anything wrong with displaying an estimate of what software is in use. What I'm complaining about is picking a single criteria and sticking a notice on it as if it were a privacy problem when it's really just a weak signal of the source software among many.
312 2019-03-08T08:03:40  <gmaxwell> it would be like sticking a warning on BIP69 txn. They're a minority of transactions so in that sense they hurt the user's privacy.
313 2019-03-08T08:04:23  <gmaxwell> But I don't think it should have a warning because it's not a privacy problem except leaking information about the source software that is probably leaked in a dozen other ways too.
314 2019-03-08T08:05:06  <shesek> well, its not just a single criteria though, there are 7 now and I'm looking to add more
315 2019-03-08T08:05:17  <shesek> how about if it looked less like a warning and more like informational text?
316 2019-03-08T08:05:38  <gmaxwell> or closer to home, you could put a nice little warning on blockstream GA transactions, they're super identifyable due to their scripts, and only a very small percentage.
317 2019-03-08T08:06:14  <shesek> oh yes, can definitely identify weird script patterns and notify about them
318 2019-03-08T08:06:47  <shesek> like, displaying a message if the script pattern is used by <X% of transactions sounds very reasonable to me
319 2019-03-08T08:07:49  <gmaxwell> I think this is likely to hurt users by randomizing preferences.
320 2019-03-08T08:07:52  <shesek> I mean, until we have taproot, using something like GA does have a very real privacy cost
321 2019-03-08T08:08:29  <gmaxwell> the problem is that singling out practices make them seem bad. even if in fact they are massive privacy improvements, long run, and we're just waiting for everyone to catch up.
322 2019-03-08T08:09:20  <shesek> but you agreed earlier that mixed output type is a real concern, and this is also caused because we're waiting for everyone to catch up
323 2019-03-08T08:09:25  <gmaxwell> The underlying leak is that the software is identifyable, but that is (hopefully) well known, but it wouldn't hurt to make it more well known. But it also isn't going away any time soon.
324 2019-03-08T08:10:53  <gmaxwell> mixed output types are not just catchup though they're partially that. I mean they'll continue to exist for the forseeable future, the only thing that will reduce that at all is really taproot, and then only if Musig style multisig becomes ubiquitious (which is doubtful, because of accountability and additional rounds).
325 2019-03-08T08:11:09  <shesek> I mean, I did know that I was going to be flagging a large % of transactions made by segwit wallets with this "sending to a different script type" message. it felt bad knowing that I'll do that, but being an early adopter of new technology does have a real negative effect on privacy, and I think users shoudl be made more aware of this
326 2019-03-08T08:12:58  <gmaxwell> So you think it's better to pressure to users to use wallets that send all their addreses to third parties in order to avoid a privacy warning that effectively only means that the user is using software that better preserves privacy?
327 2019-03-08T08:13:10  *** schmidty has joined #bitcoin-core-dev
328 2019-03-08T08:15:52  <gmaxwell> I'm exhausted by this conversation.
329 2019-03-08T08:17:47  *** schmidty has quit IRC
330 2019-03-08T08:18:24  *** Klox has quit IRC
331 2019-03-08T08:18:40  *** jungly has joined #bitcoin-core-dev
332 2019-03-08T08:19:08  *** Klox has joined #bitcoin-core-dev
333 2019-03-08T08:19:20  *** promag has joined #bitcoin-core-dev
334 2019-03-08T08:20:03  <gmaxwell> I think estimating the software and giving some kind of probablity on that would be interesting and helpful. I think singling out by-themselves-privacy-irrelevant aspects of particular software as privacy problems is not helpful, because it will actually discourage improving privacy... and if in doing so it manages to warn more about software that is actually more private (perhaps for reasons
335 2019-03-08T08:20:03  <gmaxwell> that aren't even visible from the transaction) that that would do users and the ecosystem a terrible disservice.
336 2019-03-08T08:21:52  *** promag has quit IRC
337 2019-03-08T08:22:44  <gmaxwell> (though I think the best advice to users is that their software is always identifyable. I think it practice it pretty much always is.)
338 2019-03-08T08:22:45  *** promag has joined #bitcoin-core-dev
339 2019-03-08T08:22:54  <gmaxwell> (either through the transactions or from network analytics)
340 2019-03-08T08:25:22  <shesek> I think its better to provide tools and information to help users make educated decisions. hiding the fact that early segwit adopters leak more information about their change outputs because users might misunderstand what this means and use worse non-segwit wallets is not a solution, imo. better education and better tools that make more information accessible to the user are
341 2019-03-08T08:25:53  <shesek> I do agree that the information could be presented better - maybe some more metrics, make some of them look less like warnings and more like informational text, etc. maybe re-organize it and display some of the metrics outside of the "privacy analysis" area.
342 2019-03-08T08:26:27  <gmaxwell> that aregument would be stronger if your coverage were actually even.
343 2019-03-08T08:27:00  <shesek> even?
344 2019-03-08T08:27:16  *** harding has quit IRC
345 2019-03-08T08:27:21  <gmaxwell> consistent. unbiased. e.g. all through our earlier discussion, you singled out behaviors of bitcoin because they aren't done by electrum, yet bitcoin core is responsible for a much larger share of transactions, so you're litterally singling out the larger anonymity set.
346 2019-03-08T08:29:08  *** harding has joined #bitcoin-core-dev
347 2019-03-08T08:29:11  <shesek> not specifically electrum, quite a lot of other wallet software that I've had experience with. but yes, agreed, I didn't appreciate how good bitcoin core was at avoiding change, and didn't realize that it might break UIH-2 quite often
348 2019-03-08T08:32:41  <shesek> I will run some analysis on historical block chain data, there's a lot that can be learned from it. one thing that I'm interested in is the percent of two outputs transactions that match UIH-2. will come back with numbers :)
349 2019-03-08T08:34:08  <gmaxwell> You might want to look over time, you may see the release when bitcoin core wouldn't violate UIH-2.
350 2019-03-08T08:34:24  <gmaxwell> (you can also see that period on graphs of the utxo set size. :( )
351 2019-03-08T08:39:16  <shesek> re "I think estimating the software and giving some kind of probablity on that would be interesting and helpful", you don't feel this would be "helping the other side" too much? doing some basic heuristics that are obviously done by every blockchain spying company in existence is one thing, getting smart about this and making some not so easily obtainable private data public is getting into murky territory
352 2019-03-08T08:40:01  <shesek> I'm not here to develop sophisticated spying tools :)
353 2019-03-08T08:40:50  <shesek> but, I don't know, its hard to tell where to draw the line. one could definitely argue that its better for everyone to have these tools if some people have them
354 2019-03-08T08:41:19  <gmaxwell> well you could apply this to any of this but I think the reasoning is that esp 100% public data, stuff like these determinations are things that anyone remotely competent could do.
355 2019-03-08T08:42:12  <gmaxwell> you could do something like take all the properties that identify the wallet, stick them into a generic clustering tool. and then just return a probablity for cluster1/cluster2/cluster3/cluster...n.
356 2019-03-08T08:42:51  <gmaxwell> and a metric of how common that pattern is like the panopticlick metrics.
357 2019-03-08T08:43:25  <gmaxwell> which would be more useful for user in seeing privacy levels but less useful for tracking particular people.
358 2019-03-08T08:43:57  <gmaxwell> and also easier to maintain, as you don't need to go looking at how wallet work and how they change over time.
359 2019-03-08T08:45:06  <gmaxwell> just take a bunch of features (inputs/outputs ordered?, nlocktime, oorbf, uih, script types, signature sizes,... ) and feed it to a k-medians or whatnot.
360 2019-03-08T08:45:48  <shesek> what is the oo in oorbf?
361 2019-03-08T08:47:52  <gmaxwell> opt in rbf... it's a flag set in the sequence numbers. right now I think electrum is the only widely used wallet that sets it by default (ga does too, IIRC)
362 2019-03-08T08:47:59  <gmaxwell> bitcoin core can but its a setting.
363 2019-03-08T08:49:35  <gmaxwell> though also some services that run core set it, so it might be a non-trivial percentage of core txn even though its not a default.
364 2019-03-08T08:50:46  <gmaxwell> The idea with clustering is that you can basically give every transaction a poition in n-dimensional space (all the flags), and then estimate what percentage of transactions are similar to it vs far from it.
365 2019-03-08T08:51:09  *** cornfeedhobo has quit IRC
366 2019-03-08T08:51:15  <shesek> I know what is opt in rbg, but why two oo? never seen it written as "oorbf", google didn't bring up anything either
367 2019-03-08T08:51:27  <shesek> * rbf
368 2019-03-08T08:52:16  <gmaxwell> oo was inteded to be oi -- the keys are next to each other on qwerty. Sorry. :P
369 2019-03-08T08:52:34  <gmaxwell> (or maybe I was thinking opt-out who knows)
370 2019-03-08T08:53:03  <shesek> oh okay :)
371 2019-03-08T08:54:33  *** fanquake has quit IRC
372 2019-03-08T08:55:09  *** cornfeedhobo has joined #bitcoin-core-dev
373 2019-03-08T08:55:32  <shesek> yeah, this definitely makes sense, I've done some work with similar clustering before. but I'm still not quite sure if I feel this falls under something "anyone remotely competent could do", this could make some information that's not so trivial much more trivial
374 2019-03-08T08:56:01  <shesek> even if its based just on public data, I still feel the line can be crossed
375 2019-03-08T08:56:38  <gmaxwell> What I don't think would help the public though is if you were going and reading the code for a dozen wallets to extract their behaivor, thats a lot of custom work... don't give that to the badguys for free.
376 2019-03-08T08:57:09  <gmaxwell> stats on well known data is something I can go on freelancer and pay someone to do though.
377 2019-03-08T09:00:27  <shesek> do you think that the data being public is a sufficient criteria for this being moral? I think the amount of effort, experience and creativity that was devoted to it should count too
378 2019-03-08T09:01:46  <shesek> like, if someone devoted a year of a team of developers to building tools that extract private information from public blockchains, and setup a website making all of this information publicly available, I would consider him to be on the bad side
379 2019-03-08T09:03:11  <shesek> maybe easier to think about this as "overall negative or positive effect on bitcoin users' privacy" than in morality terms
380 2019-03-08T09:06:53  <gmaxwell> no, I don't think the data being public is the line.
381 2019-03-08T09:06:55  <wumpus> i think i disagree, sometimes it take a public statement like that to show people how information is available, the "bad guys" will be doing the same but without letting anyone know, of course
382 2019-03-08T09:07:07  *** anome has joined #bitcoin-core-dev
383 2019-03-08T09:07:32  <gmaxwell> but for example, if you already know that commercial anti-privacy services are doing it, I think it's likely pretty beneficial to make it public.
384 2019-03-08T09:08:02  *** anome has quit IRC
385 2019-03-08T09:08:20  <shesek> right, so no state-of-the-art stuff, only things you believe are likely already being done by component companies
386 2019-03-08T09:08:26  <gmaxwell> Right.
387 2019-03-08T09:08:27  <shesek> I guess this could be a good line
388 2019-03-08T09:08:40  <wumpus> and you never know that
389 2019-03-08T09:08:59  <wumpus> if you can think of it, someone at the NSA probably thought of it too
390 2019-03-08T09:09:58  <gmaxwell> Also, if you can think of the idea and getsomeone on fiverr to implement it, thats less harmful than something where a 5 year bitcoin expert has two spend three weeks extracting behavior patterns from codebases.
391 2019-03-08T09:10:17  *** smarti has joined #bitcoin-core-dev
392 2019-03-08T09:10:27  <gmaxwell> Also depends on what attacker we're thinking about. Like, the state level attackers if they don't know essentially anything we do here, it's only because they don't care.
393 2019-03-08T09:10:45  <gmaxwell> the commercial anti-privacy services seem to have kind of mixed competence.
394 2019-03-08T09:11:01  *** anome has joined #bitcoin-core-dev
395 2019-03-08T09:11:43  <gmaxwell> like I can imagine that some have never realized you could use UIH to distinguish some wallet software.
396 2019-03-08T09:12:03  <wumpus> that's definitely true
397 2019-03-08T09:12:08  *** mmgen has joined #bitcoin-core-dev
398 2019-03-08T09:12:45  <gmaxwell> and I've seen ones make mistakes like "output type matches input scripts, that certantly change" and as a result gets all kinds of messed up conclusions. :)
399 2019-03-08T09:13:20  <gmaxwell> I've typed a couple other things here and erased them to not give people ideas. :P
400 2019-03-08T09:13:57  <wumpus> indeed, provoostenator wrote about those kind of things, it's kind of worrying, false positives are the most scary especially when they're used to decide who to prosecute or rob or kill etc
401 2019-03-08T09:14:05  <gmaxwell> in any case, you can always ask the question "how does doing this thing make a better world, how does it make a worse one"
402 2019-03-08T09:14:51  <gmaxwell> shesek: so another criteria is that you might have some good indicator but if its not actionable by users, it's not as interesting to show... as another one where the user could just change what they're doing.
403 2019-03-08T09:16:31  <shesek> I used this criteria to decide what to display in red and what in orange https://github.com/Blockstream/esplora/blob/dev/client/src/views/tx-privacy-analysis.js#L5-L7
404 2019-03-08T09:16:52  *** anome has quit IRC
405 2019-03-08T09:17:05  <shesek> but I think the orange stuff should mostly be changed to non-warnings, just informational text, some of it maybe outside the privacy section
406 2019-03-08T09:19:05  <shesek> and some of the texts could use some corrections/clarification
407 2019-03-08T09:23:36  *** fanquake has joined #bitcoin-core-dev
408 2019-03-08T09:26:38  <shesek> I'm off, going to get some food. thanks for the interesting chat, I learned quite a bit. I'll definitely look for ways to improve based on your feedback. will also run an historical analysis and get back with some numbers. cheers :)
409 2019-03-08T09:29:07  *** timothy has joined #bitcoin-core-dev
410 2019-03-08T09:30:52  *** owowo has quit IRC
411 2019-03-08T09:31:26  *** promag_ has joined #bitcoin-core-dev
412 2019-03-08T09:35:52  *** owowo has joined #bitcoin-core-dev
413 2019-03-08T09:40:34  *** setpill has joined #bitcoin-core-dev
414 2019-03-08T09:47:01  *** jonatack_ has joined #bitcoin-core-dev
415 2019-03-08T09:47:03  *** anome has joined #bitcoin-core-dev
416 2019-03-08T09:50:12  *** anome has quit IRC
417 2019-03-08T09:51:35  *** jonatack_ has quit IRC
418 2019-03-08T10:03:37  *** kexkey has quit IRC
419 2019-03-08T10:08:10  <fanquake> At least one issue reported for rc1 so far, https://github.com/bitcoin/bitcoin/issues/15555#issuecomment-470827939, although need more info.
420 2019-03-08T10:09:03  *** mmgen has quit IRC
421 2019-03-08T10:11:27  <fanquake> I guess related to #14561
422 2019-03-08T10:11:29  <gribble> https://github.com/bitcoin/bitcoin/issues/14561 | Remove fs::relative call and fix listwalletdir tests by promag · Pull Request #14561 · bitcoin/bitcoin · GitHub
423 2019-03-08T10:11:39  *** promag has quit IRC
424 2019-03-08T10:11:53  *** mmgen has joined #bitcoin-core-dev
425 2019-03-08T10:12:19  *** promag has joined #bitcoin-core-dev
426 2019-03-08T10:14:27  *** schmidty has joined #bitcoin-core-dev
427 2019-03-08T10:18:45  *** schmidty has quit IRC
428 2019-03-08T10:22:32  *** smarti has quit IRC
429 2019-03-08T10:22:42  *** fuqaiq has joined #bitcoin-core-dev
430 2019-03-08T10:23:58  *** fuqaiq has quit IRC
431 2019-03-08T10:29:49  *** vexbuy has joined #bitcoin-core-dev
432 2019-03-08T10:32:17  *** vexbuy has quit IRC
433 2019-03-08T10:34:41  *** anome has joined #bitcoin-core-dev
434 2019-03-08T10:35:02  *** anome has quit IRC
435 2019-03-08T10:37:09  <gmaxwell> When should we start thinking about making bech32 the default -addresstype ?   We've been able to send to bc1 addresses since 0.16.0 which was released feb 2018.
436 2019-03-08T10:37:29  <gmaxwell> Should it be a goal for 0.19? 0.20?
437 2019-03-08T10:38:02  <gmaxwell> Bitcoin core makes it pretty easy to get other addresses when you need them for compatiblity, fortunately.
438 2019-03-08T10:39:07  <gmaxwell> when satoshi completely broke compatiblity with the p2p protocol, he gave two years time for people to upgrade. On one hand, that was a much harder break, on the other hand, it as a much smaller ecosystem at that time.
439 2019-03-08T10:39:48  <gmaxwell> I'm somewhat disappointed to see that some parties that I've past identified as tech leaders still don't have sending support... which is an argument against rushing.
440 2019-03-08T10:40:12  <gmaxwell> But maybe announcing a plan to default by version X might help some parties prioritize.
441 2019-03-08T10:46:13  *** anome has joined #bitcoin-core-dev
442 2019-03-08T10:48:55  *** anome has quit IRC
443 2019-03-08T10:49:13  *** anome has joined #bitcoin-core-dev
444 2019-03-08T10:49:46  *** anome has quit IRC
445 2019-03-08T10:49:57  *** zhangzf has quit IRC
446 2019-03-08T10:51:59  *** schmidty has joined #bitcoin-core-dev
447 2019-03-08T10:52:32  *** timothy has quit IRC
448 2019-03-08T10:56:35  *** schmidty has quit IRC
449 2019-03-08T11:00:03  *** spinza has quit IRC
450 2019-03-08T11:11:18  *** Victorsueca has quit IRC
451 2019-03-08T11:12:06  *** Victorsueca has joined #bitcoin-core-dev
452 2019-03-08T11:19:06  *** spinza has joined #bitcoin-core-dev
453 2019-03-08T11:23:57  *** schmidty has joined #bitcoin-core-dev
454 2019-03-08T11:23:57  *** schmidty has joined #bitcoin-core-dev
455 2019-03-08T11:24:15  *** timothy has joined #bitcoin-core-dev
456 2019-03-08T11:27:03  *** AaronvanW has joined #bitcoin-core-dev
457 2019-03-08T11:37:32  *** owowo has quit IRC
458 2019-03-08T11:38:33  *** owowo has joined #bitcoin-core-dev
459 2019-03-08T11:51:03  *** anome has joined #bitcoin-core-dev
460 2019-03-08T12:23:18  <instagibbs> a hotter take would be to make segwit v1 unenforced inside p2sh
461 2019-03-08T12:24:05  <instagibbs> bad idea for money-loss reasons :)
462 2019-03-08T12:26:59  *** anome has quit IRC
463 2019-03-08T12:28:24  *** anome has joined #bitcoin-core-dev
464 2019-03-08T12:30:50  <gmaxwell> I dunno if it would be likely to result in money loss.
465 2019-03-08T12:31:05  <gmaxwell> There is a fine line between encouragement and arm bending though.
466 2019-03-08T12:31:24  <gmaxwell> if it's taking e.g. ledger >1 year to add support, maybe more encouragement is required.
467 2019-03-08T12:43:08  *** Aaronvan_ has joined #bitcoin-core-dev
468 2019-03-08T12:46:05  <fanquake> fwiw i opened #15560 for discussion
469 2019-03-08T12:46:06  <gribble> https://github.com/bitcoin/bitcoin/issues/15560 | When to make bech32 the default -addresstype? · Issue #15560 · bitcoin/bitcoin · GitHub
470 2019-03-08T12:46:24  *** AaronvanW has quit IRC
471 2019-03-08T12:58:49  <luke-jr> IMO making segwit v1 unenforced inside p2sh is more of bludgeoning than arm bending :P
472 2019-03-08T12:59:58  <luke-jr> (policy rejection might be more like arm bending)
473 2019-03-08T13:03:03  *** jonatack has joined #bitcoin-core-dev
474 2019-03-08T13:06:45  *** promag_ has quit IRC
475 2019-03-08T13:13:03  *** hex17or has quit IRC
476 2019-03-08T13:18:22  *** Skirmant has quit IRC
477 2019-03-08T13:20:56  *** spaced0ut has joined #bitcoin-core-dev
478 2019-03-08T13:35:45  *** setpill has quit IRC
479 2019-03-08T13:38:57  *** captjakk has joined #bitcoin-core-dev
480 2019-03-08T13:43:25  *** captjakk has quit IRC
481 2019-03-08T13:52:35  *** tryphe has quit IRC
482 2019-03-08T13:53:01  *** tryphe has joined #bitcoin-core-dev
483 2019-03-08T13:55:27  *** Aaronvan_ is now known as AaronvanW
484 2019-03-08T14:13:37  *** bitcoin-git has joined #bitcoin-core-dev
485 2019-03-08T14:13:37  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d211edb34982...923d87497c7c
486 2019-03-08T14:13:38  <bitcoin-git> bitcoin/master fa58a2e MarcoFalke: contrib: Bump gitian descriptors for 0.19
487 2019-03-08T14:13:38  <bitcoin-git> bitcoin/master 923d874 MarcoFalke: Merge #15528: contrib: Bump gitian descriptors for 0.19
488 2019-03-08T14:13:40  *** bitcoin-git has left #bitcoin-core-dev
489 2019-03-08T14:14:20  *** bitcoin-git has joined #bitcoin-core-dev
490 2019-03-08T14:14:21  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #15528: contrib: Bump gitian descriptors for 0.19 (master...1903-gitian19) https://github.com/bitcoin/bitcoin/pull/15528
491 2019-03-08T14:14:25  *** bitcoin-git has left #bitcoin-core-dev
492 2019-03-08T14:20:06  *** Skirmant has joined #bitcoin-core-dev
493 2019-03-08T14:26:53  *** bitcoin-git has joined #bitcoin-core-dev
494 2019-03-08T14:26:53  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/923d87497c7c...efed9809b4fa
495 2019-03-08T14:26:53  <bitcoin-git> bitcoin/master 82c3b3f practicalswift: Remove sharp edge (uninitialized m_filter_type) when using the compiler-ge...
496 2019-03-08T14:26:54  <bitcoin-git> bitcoin/master efed980 Wladimir J. van der Laan: Merge #15532: Remove sharp edge (uninit member) when using the compiler-ge...
497 2019-03-08T14:26:56  *** bitcoin-git has left #bitcoin-core-dev
498 2019-03-08T14:27:33  *** bitcoin-git has joined #bitcoin-core-dev
499 2019-03-08T14:27:33  <bitcoin-git> [bitcoin] laanwj merged pull request #15532: Remove sharp edge (uninit member) when using the compiler-generated ctor for BlockFilter (master...BlockFilterType) https://github.com/bitcoin/bitcoin/pull/15532
500 2019-03-08T14:27:45  *** bitcoin-git has left #bitcoin-core-dev
501 2019-03-08T14:35:02  *** Guyver2 has joined #bitcoin-core-dev
502 2019-03-08T14:43:53  *** promag has quit IRC
503 2019-03-08T14:44:07  *** promag has joined #bitcoin-core-dev
504 2019-03-08T14:49:29  *** promag_ has joined #bitcoin-core-dev
505 2019-03-08T14:49:29  *** promag has quit IRC
506 2019-03-08T15:17:35  *** hex17or has joined #bitcoin-core-dev
507 2019-03-08T15:18:40  *** hex17or has quit IRC
508 2019-03-08T15:19:36  *** hex17or has joined #bitcoin-core-dev
509 2019-03-08T15:21:15  *** jonatack has quit IRC
510 2019-03-08T15:23:37  *** hebasto has joined #bitcoin-core-dev
511 2019-03-08T15:24:57  *** zhangzf has joined #bitcoin-core-dev
512 2019-03-08T15:31:16  *** anome has quit IRC
513 2019-03-08T15:38:17  *** cubancorona has quit IRC
514 2019-03-08T15:38:38  *** cubancorona has joined #bitcoin-core-dev
515 2019-03-08T15:39:53  *** hebasto has quit IRC
516 2019-03-08T15:43:13  *** asdfgarev has joined #bitcoin-core-dev
517 2019-03-08T16:05:05  *** jarthur has joined #bitcoin-core-dev
518 2019-03-08T16:06:07  *** AaronvanW has quit IRC
519 2019-03-08T16:06:42  *** AaronvanW has joined #bitcoin-core-dev
520 2019-03-08T16:09:44  *** elichai2 has joined #bitcoin-core-dev
521 2019-03-08T16:21:33  *** Soligor has joined #bitcoin-core-dev
522 2019-03-08T16:34:03  *** zhangzf has quit IRC
523 2019-03-08T16:36:10  *** Guyver2 has quit IRC
524 2019-03-08T16:36:47  *** Guyver2 has joined #bitcoin-core-dev
525 2019-03-08T16:48:17  *** tryphe has quit IRC
526 2019-03-08T16:48:28  *** promag_ has quit IRC
527 2019-03-08T16:48:47  *** tryphe has joined #bitcoin-core-dev
528 2019-03-08T16:49:00  *** promag has joined #bitcoin-core-dev
529 2019-03-08T17:03:06  *** spinza has quit IRC
530 2019-03-08T17:07:10  *** Bullit has quit IRC
531 2019-03-08T17:07:51  *** jungly has quit IRC
532 2019-03-08T17:12:24  *** Bullit has joined #bitcoin-core-dev
533 2019-03-08T17:13:55  *** spinza has joined #bitcoin-core-dev
534 2019-03-08T17:28:00  *** ap4lmtree has quit IRC
535 2019-03-08T17:28:22  *** ap4lmtree has joined #bitcoin-core-dev
536 2019-03-08T17:48:19  *** tryphe has quit IRC
537 2019-03-08T17:48:46  *** tryphe has joined #bitcoin-core-dev
538 2019-03-08T17:49:13  *** qrestlove has joined #bitcoin-core-dev
539 2019-03-08T17:50:19  *** promag_ has joined #bitcoin-core-dev
540 2019-03-08T17:56:35  *** Deinogalerix21 has joined #bitcoin-core-dev
541 2019-03-08T18:02:26  *** anome has joined #bitcoin-core-dev
542 2019-03-08T18:06:32  *** Deinogalerix21 has quit IRC
543 2019-03-08T18:17:38  *** promag_ has quit IRC
544 2019-03-08T18:30:03  *** IGHOR has quit IRC
545 2019-03-08T18:31:14  *** IGHOR has joined #bitcoin-core-dev
546 2019-03-08T18:33:46  *** anome has quit IRC
547 2019-03-08T18:39:10  *** anome has joined #bitcoin-core-dev
548 2019-03-08T18:42:55  *** pinheadmz has quit IRC
549 2019-03-08T18:43:29  *** anome has quit IRC
550 2019-03-08T18:43:31  *** timothy has quit IRC
551 2019-03-08T18:48:23  *** shesek has quit IRC
552 2019-03-08T18:48:27  <gmaxwell> My list of banworthy unsubtle bitcoin spies and mass connectors has been updated!  https://people.xiph.org/~greg/banlist.cli.txt https://people.xiph.org/~greg/banlist.gui.txt
553 2019-03-08T18:50:45  *** pinheadmz has joined #bitcoin-core-dev
554 2019-03-08T18:54:33  *** anome has joined #bitcoin-core-dev
555 2019-03-08T18:58:52  *** jonatack_ has joined #bitcoin-core-dev
556 2019-03-08T18:59:39  <sdaftuar> at what point do you think we can nuke getblocks support, and reasonably assume that peers should be using getheaders instead?
557 2019-03-08T19:02:11  <gmaxwell> Uh, instrument a node and see if anyone is using it now?
558 2019-03-08T19:02:42  <gmaxwell> (I'm not saying now, but even knowing when would require knowing what use is now)
559 2019-03-08T19:03:33  <gmaxwell> I hadn't been thinking we would depricate responding to it, but if its not being used anymore then maybe.
560 2019-03-08T19:03:33  <sdaftuar> i found a bcoin:1.0.2 peer that seems to be using it :( somehow that peer also supports compact blocks(?!)
561 2019-03-08T19:04:27  <gmaxwell> okay well there are like three of those on the network, and AFAIK that software is only maintained for bcash anymore, so that wouldn't be a hard blocker, I think.
562 2019-03-08T19:04:36  <sdaftuar> i was looking at some net stuff that i'd like to refactor a bit to make things more efficient for blocksonly peers (i think i mentioned to you my idea of adding blocksonly edges to the network).  would be nice to ditch some of this old unused code.
563 2019-03-08T19:05:40  <gmaxwell> also careful with believing subver, there is a bunch of stuff that lies. (though in this case I'd believe it)
564 2019-03-08T19:05:49  *** anome has quit IRC
565 2019-03-08T19:06:49  *** anome has joined #bitcoin-core-dev
566 2019-03-08T19:08:51  *** pinheadmz has quit IRC
567 2019-03-08T19:10:58  *** anome has quit IRC
568 2019-03-08T19:13:16  *** anome has joined #bitcoin-core-dev
569 2019-03-08T19:14:59  *** rex4539 has quit IRC
570 2019-03-08T19:16:11  *** rex4539 has joined #bitcoin-core-dev
571 2019-03-08T19:17:22  *** anome has quit IRC
572 2019-03-08T19:18:29  *** rex4539 has joined #bitcoin-core-dev
573 2019-03-08T19:24:21  *** millerti has joined #bitcoin-core-dev
574 2019-03-08T19:24:41  *** promag_ has joined #bitcoin-core-dev
575 2019-03-08T19:28:58  *** promag_ has quit IRC
576 2019-03-08T19:35:38  *** pinheadmz has joined #bitcoin-core-dev
577 2019-03-08T19:36:47  <pinheadmz> gmaxwell: I'm a dev on bcoin team, i can tell you bcash is being not supported. bcoin is our main focus
578 2019-03-08T19:42:07  <sipa> a surprising error: i can't run the bitcoind unit tests simultaneously by two different users on my system, as they both try to create a /tmp/test_bitcoin owned by themselves
579 2019-03-08T19:42:44  <pinheadmz> sdaftuar: can you explain a bit more the behavior you're seeing from that peer? In my own research I notice bcoin does send getblocks instead of getheaders, unless checkpoints are enabled
580 2019-03-08T19:43:29  <sdaftuar> pinheadmz: i'm just looking at the stats for data received by p2p message type, and i noticed that for a peer claiming to be bcoin 1.0.2 there are only getblocks messages, and no getheaders messages, being received by my node
581 2019-03-08T19:43:56  <sdaftuar> i also notice plenty of other normal-looking traffic from that peer (inv, cmpctblocks, headers, etc)
582 2019-03-08T19:44:57  <pinheadmz> when I test against Bitcoin Core, I noticed Core sent getheaders first, then getdata for the actual blocks
583 2019-03-08T19:45:21  <sdaftuar> yes, that makes sense to me
584 2019-03-08T19:45:33  <pinheadmz> bcoin does support compact blocks, why is that a (?!) :-)
585 2019-03-08T19:46:15  <sdaftuar> getblocks is just a deprecated message (or so i thought) -- compact blocks build on top of the headers p2p protocol messages that were added much later
586 2019-03-08T19:46:41  <sdaftuar> so i would have assumed anyone implemented compact blocks would have swithced to getheaders
587 2019-03-08T19:47:35  *** anome has joined #bitcoin-core-dev
588 2019-03-08T19:47:41  *** tryphe has quit IRC
589 2019-03-08T19:48:07  *** tryphe has joined #bitcoin-core-dev
590 2019-03-08T19:48:32  *** jcorgan has joined #bitcoin-core-dev
591 2019-03-08T19:48:52  *** shesek has joined #bitcoin-core-dev
592 2019-03-08T19:48:52  *** shesek has joined #bitcoin-core-dev
593 2019-03-08T19:48:59  <sdaftuar> pinheadmz: any idea why bcoin still uses getblocks? sounds like you are saying that sometimes it uses getheaders instead?
594 2019-03-08T19:49:55  *** anome has quit IRC
595 2019-03-08T19:51:23  *** anome has joined #bitcoin-core-dev
596 2019-03-08T19:51:23  <pinheadmz> looking into it now... is the deprecation of getblocks documented? I was about to start work on BIP159 (NETWORK_LIMITED) but maybe I should checkout the existing networkprotocol behavior first. bcoin does send `sendcmpct` and then `getblocks` which will retrieve compact blocks from the peer.
597 2019-03-08T19:51:37  *** jcorgan_ has quit IRC
598 2019-03-08T19:51:41  <pinheadmz> Actually Im curious why Core sends `getheaders` first, an then requests the full blocks?
599 2019-03-08T19:51:59  <sipa> pinheadmz: how would it know what blocks to fetch?
600 2019-03-08T19:52:23  <sdaftuar> pinheadmz: no, it being deprecated is just in my head, that was how i thought about. i think bitcoin core hasn't sent getblocks messages in 5+ years or so.
601 2019-03-08T19:52:25  <sipa> you can find out the block hashes using getblocks or getheaders, but the latter lets you verify PoW before fetching the actual blocks
602 2019-03-08T19:52:25  <pinheadmz> from `inv`
603 2019-03-08T19:52:33  <pinheadmz> makes sense
604 2019-03-08T19:52:39  <sipa> pinheadmz: that's only for newly mined blocks
605 2019-03-08T19:52:49  <sipa> (or in response to getblocks...)
606 2019-03-08T19:53:13  <sipa> and with BIP130, new blocks are also announced using headers instead of invs
607 2019-03-08T19:53:30  <sipa> but that's optionally negotiated between peers
608 2019-03-08T19:53:42  <gmaxwell> sdaftuar: I considered it deprecated too, fwiw, (though didn't expect it to get disabled anytime soon-- it's just useless/redundant now)
609 2019-03-08T19:54:19  <gmaxwell> pinheadmz: a header is not much larger than an INV but radically more useful.
610 2019-03-08T19:54:33  <gmaxwell> pinheadmz: so essentially for blocks we'd replaced INVs with headers.
611 2019-03-08T19:54:45  <sipa> i suspect there are a number of tools (perhaps block fetching analysis stuff) that use getblocks/inv/getdata/blocks still, which you probably won't see on the public network but are still pretty useful to support
612 2019-03-08T19:55:02  <pinheadmz> gmaxwell: ok thanks I see this now. SO `getheaders` asks the peer to just send headers without an `inv`
613 2019-03-08T19:55:18  <pinheadmz> same behavior with SPV wallets
614 2019-03-08T19:55:18  <sipa> pinheadmz: it sends headers instead of inv
615 2019-03-08T19:55:24  <gmaxwell> pinheadmz: yes, its pretty much exactly like getblocks but sends headers.
616 2019-03-08T19:55:29  *** ap4lmtree has quit IRC
617 2019-03-08T19:55:47  <pinheadmz> then headers are verified, then `getdata` with block hashses
618 2019-03-08T19:55:53  <sdaftuar> right
619 2019-03-08T19:55:56  <sipa> right
620 2019-03-08T19:56:00  <gmaxwell> right
621 2019-03-08T19:56:16  <sipa> bitcoin core since 0.10 uses this as synchronization mechanism; it's called headers-first sync
622 2019-03-08T19:56:36  <tryphe> how were blocks gotten before getheaders again? just block #? the new way has much better performance
623 2019-03-08T19:57:06  <gmaxwell> pinheadmz: also they are not fetched with getdata if they are possible the best chain, if they're guarenteed to be worse, they're not fetched. This avoids some block flooding denial of service attacks.
624 2019-03-08T19:57:35  <sipa> tryphe: getblocks -> inv -> getdata -> block
625 2019-03-08T19:57:56  <sipa> getblocks takes a locator and a count, and responds with an inv announcing the next count block hashesd
626 2019-03-08T19:58:16  *** anome has quit IRC
627 2019-03-08T19:58:17  <sipa> iirc
628 2019-03-08T19:58:28  <sipa> the protocol doesn't expose anything by height
629 2019-03-08T19:58:41  <sipa> as height is ambiguous in the presence of brances
630 2019-03-08T19:59:16  <sdaftuar> that's basically right.  there's also this hacky thing we do where we send redundant inv's to trigger additional getblocks responses to help peers download the whole chain (since inv's are capped at 50k responses).  that's what got me to wanting to remove this :)
631 2019-03-08T19:59:27  *** shesek has quit IRC
632 2019-03-08T20:01:17  <pinheadmz> thanks guys, going to get the team on BIP130
633 2019-03-08T20:01:39  <sipa> bip130 is a step being headers-first sync
634 2019-03-08T20:01:43  <sipa> *beyond
635 2019-03-08T20:02:23  <pinheadmz> is there a spec for headers first sync? (besides, this chat :-) which i think is pretty clear)
636 2019-03-08T20:02:31  <gmaxwell> sdaftuar: yea, when you said you wanted to remove it that was what I assumed you wanted to remove.
637 2019-03-08T20:02:31  <sdaftuar> (in particular it sounds like bcoin already implements bip 152, which is a step beyond bip 130.)
638 2019-03-08T20:02:32  *** pinheadmz has left #bitcoin-core-dev
639 2019-03-08T20:02:55  <sipa> kthxbye
640 2019-03-08T20:03:03  *** Bullit has quit IRC
641 2019-03-08T20:03:22  *** pinheadmz has joined #bitcoin-core-dev
642 2019-03-08T20:03:45  <sipa> pinheadmz: no, not a spec - it's just a way of doing things, not really a protocol
643 2019-03-08T20:03:52  <sipa> (it didn't need any changes to the p2p protocol)
644 2019-03-08T20:04:09  <pinheadmz> will `getblocks` ever be unsupported?
645 2019-03-08T20:04:13  <sipa> as getheaders/headers existed for years before we started using it for block syncing
646 2019-03-08T20:04:28  <gmaxwell> pinheadmz: that was the subject of discussion.
647 2019-03-08T20:04:29  <sdaftuar> pinheadmz: i hope so, but i dunno.  i might send an email to the -dev list asking if anyone would object?
648 2019-03-08T20:04:41  <sipa> sdaftuar: seems premature at this point
649 2019-03-08T20:04:44  <sdaftuar> sipa: yeah
650 2019-03-08T20:05:03  <gmaxwell> sdaftuar: maybe wait a bit so we don't waste time with 'bcoin' objecting, at least.
651 2019-03-08T20:05:21  <sdaftuar> well i might want to at least suggest that people start thinking of it as deprecated so we can get rid of it eventually
652 2019-03-08T20:05:31  <gmaxwell> unfortunate to have to keep around the feeding hack.
653 2019-03-08T20:05:53  <gmaxwell> sdaftuar: yes, thats fair, and something we should do.
654 2019-03-08T20:06:19  <sdaftuar> pinheadmz: thanks for jumping on here to discuss
655 2019-03-08T20:06:49  <pinheadmz> thanks for bringing it up!
656 2019-03-08T20:06:55  *** Squidicuz has quit IRC
657 2019-03-08T20:11:27  <gmaxwell> getblocks has been broken since day one, the design didn't consider that an a maximum size would be needed, and one got bolted on after the fact (iirc at the beginning of 2010).
658 2019-03-08T20:44:33  *** mmgen has quit IRC
659 2019-03-08T20:51:03  *** EagleTM has joined #bitcoin-core-dev
660 2019-03-08T20:56:42  *** booyah has quit IRC
661 2019-03-08T20:56:44  *** nullptr| has quit IRC
662 2019-03-08T20:57:31  *** booyah has joined #bitcoin-core-dev
663 2019-03-08T21:01:12  *** nullptr| has joined #bitcoin-core-dev
664 2019-03-08T21:04:06  *** pinheadmz has quit IRC
665 2019-03-08T21:04:24  <sipa> gmaxwell: i'm gathering statistics on the prevalance of lowr transactions... and the numbers are surprisingly inconsistent when broken down by #sigs/tx
666 2019-03-08T21:04:26  *** pinheadmz has joined #bitcoin-core-dev
667 2019-03-08T21:05:03  <sipa> for 1 sig/tx: 3.4% above 1/2
668 2019-03-08T21:05:17  <sipa> for 2 sig/tx: 4.9% above 1/4
669 2019-03-08T21:05:29  <sipa> for 3 sig/tx: 8.6% above 1/8
670 2019-03-08T21:05:45  *** Aaronvan_ has joined #bitcoin-core-dev
671 2019-03-08T21:06:10  <sipa> for 4 sig/tx: 7.2% above 1/16
672 2019-03-08T21:06:38  <sipa> for 5 sig/tx: 11.6% abive 1/32
673 2019-03-08T21:06:46  <sipa> for 6 sig/tx: 5% above 1/64
674 2019-03-08T21:06:57  <sipa> for 7 sig/tx: 10.9% above 1/128
675 2019-03-08T21:08:03  <gmaxwell> why are you changing the threshold and number of sigs?
676 2019-03-08T21:09:12  *** AaronvanW has quit IRC
677 2019-03-08T21:10:47  *** AaronvanW has joined #bitcoin-core-dev
678 2019-03-08T21:13:40  *** ap4lmtree has joined #bitcoin-core-dev
679 2019-03-08T21:13:47  *** Aaronvan_ has quit IRC
680 2019-03-08T21:13:48  *** promag has quit IRC
681 2019-03-08T21:14:04  *** promag has joined #bitcoin-core-dev
682 2019-03-08T21:14:24  <sipa> gmaxwell: because in  tx with 5 sigs, there is a 1/32 chance that non-lowr wallets will produce a lowr solution anyway
683 2019-03-08T21:15:57  <gmaxwell> oh I thought that was the definition of lowness. :)
684 2019-03-08T21:16:39  <sipa> gmaxwell: oh, i see my statement may be misinterpreted
685 2019-03-08T21:17:06  <sipa> i mean for 5 sig/tx, (11.6% + 1/32) of transactions are fully lowr
686 2019-03-08T21:17:19  <gmaxwell> I'd expect bitcoin core users and ones that update more actively to consume more inputs... due to being larger more active wallets, and due to BNB.
687 2019-03-08T21:25:59  *** Guyver2 has quit IRC
688 2019-03-08T21:26:46  <echeveria> sipa: I'd expect that really.
689 2019-03-08T21:27:46  <echeveria> sipa: some forms of multisig are basically unique to specific software. almost all 11 of 15 transactions are going to be Blockstream's Liquid, for example. a large portion of 2 of 2 are going to be GreenAddress. people aren't really going out and making custom multisig sets outside of outliers.
690 2019-03-08T21:29:08  <echeveria> when I was looking into this a month or two ago I was surprised to see a small number of multisig transactions that combined uncompressed and compressed keys. that bucks the trend and goes against my previous statement.
691 2019-03-08T21:29:30  <echeveria> there's a very small number of 1 of 1 P2SH transactions too.
692 2019-03-08T21:29:43  <gmaxwell> the coinjoin bounty fund is a mixed compressed multisig.
693 2019-03-08T21:31:36  <echeveria> looking at the spend sets for multisig was interesting too. a number use a fixed third key and two other keys that vary. what signatures are made for multiple spends of the same script, too. is it always a fixed combination that satisfies, or a dynamic say, 2 keys of 3.
694 2019-03-08T21:32:49  *** Aaronvan_ has joined #bitcoin-core-dev
695 2019-03-08T21:33:10  *** promag has quit IRC
696 2019-03-08T21:33:46  *** promag has joined #bitcoin-core-dev
697 2019-03-08T21:35:47  *** jarthur has quit IRC
698 2019-03-08T21:35:53  *** AaronvanW has quit IRC
699 2019-03-08T21:43:57  *** tryphe has quit IRC
700 2019-03-08T21:44:21  *** tryphe has joined #bitcoin-core-dev
701 2019-03-08T21:51:45  *** afk11 has quit IRC
702 2019-03-08T21:55:54  *** spinza has quit IRC
703 2019-03-08T22:02:44  *** dviola has joined #bitcoin-core-dev
704 2019-03-08T22:03:35  *** promag_ has joined #bitcoin-core-dev
705 2019-03-08T22:04:57  *** promag_ has quit IRC
706 2019-03-08T22:05:30  *** Squidicuz has joined #bitcoin-core-dev
707 2019-03-08T22:06:05  *** spinza has joined #bitcoin-core-dev
708 2019-03-08T22:23:08  *** pso47 has joined #bitcoin-core-dev
709 2019-03-08T22:25:53  *** promag_ has joined #bitcoin-core-dev
710 2019-03-08T22:30:03  *** promag_ has quit IRC
711 2019-03-08T22:52:01  *** spinza has quit IRC
712 2019-03-08T22:52:03  *** EagleTM has quit IRC
713 2019-03-08T22:59:59  *** spinza has joined #bitcoin-core-dev
714 2019-03-08T23:05:38  *** belcher has quit IRC
715 2019-03-08T23:08:06  *** justanotheruser has joined #bitcoin-core-dev
716 2019-03-08T23:18:45  *** belcher has joined #bitcoin-core-dev
717 2019-03-08T23:23:23  *** elichai2 has quit IRC
718 2019-03-08T23:26:22  *** promag_ has joined #bitcoin-core-dev
719 2019-03-08T23:43:08  *** AaronvanW has joined #bitcoin-core-dev
720 2019-03-08T23:45:56  *** Aaronvan_ has quit IRC
721 2019-03-08T23:57:10  *** Aaronvan_ has joined #bitcoin-core-dev
722 2019-03-08T23:58:11  *** pso47 has quit IRC