12019-03-08T00:00:16  <promag> sipa: looks like it's related to my changes
  22019-03-08T00:01:33  *** timothy has quit IRC
  32019-03-08T00:38:34  *** elichai2 has quit IRC
  42019-03-08T00:52:47  *** jarthur has quit IRC
  52019-03-08T00:53:20  *** bitcoin-git has joined #bitcoin-core-dev
  62019-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
  72019-03-08T00:53:21  *** bitcoin-git has left #bitcoin-core-dev
  82019-03-08T00:56:32  *** dviola has joined #bitcoin-core-dev
  92019-03-08T00:56:45  *** elichai2 has joined #bitcoin-core-dev
 102019-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
 112019-03-08T01:04:31  *** DeanGuss has quit IRC
 122019-03-08T01:06:18  *** jarthur has joined #bitcoin-core-dev
 132019-03-08T01:09:38  *** tryphe has quit IRC
 142019-03-08T01:10:11  *** tryphe has joined #bitcoin-core-dev
 152019-03-08T01:11:13  *** captjakk has quit IRC
 162019-03-08T01:12:19  *** jarthur has quit IRC
 172019-03-08T01:12:44  *** captjakk has joined #bitcoin-core-dev
 182019-03-08T01:13:19  *** captjakk has joined #bitcoin-core-dev
 192019-03-08T01:17:44  *** zhangzf has joined #bitcoin-core-dev
 202019-03-08T01:18:57  *** promag has quit IRC
 212019-03-08T01:24:52  *** fanquake has joined #bitcoin-core-dev
 222019-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.
 232019-03-08T01:47:01  *** jarthur has joined #bitcoin-core-dev
 242019-03-08T01:47:48  *** captjakk has quit IRC
 252019-03-08T01:48:50  *** jarthur has quit IRC
 262019-03-08T02:09:23  *** tryphe has quit IRC
 272019-03-08T02:09:51  *** tryphe has joined #bitcoin-core-dev
 282019-03-08T02:35:10  *** dviola has quit IRC
 292019-03-08T02:51:34  *** schmidty has quit IRC
 302019-03-08T02:54:29  *** schmidty has joined #bitcoin-core-dev
 312019-03-08T02:58:45  *** schmidty has quit IRC
 322019-03-08T03:03:22  *** Aaronvan_ has quit IRC
 332019-03-08T03:06:49  *** schmidty has joined #bitcoin-core-dev
 342019-03-08T03:09:23  *** tryphe has quit IRC
 352019-03-08T03:09:51  *** tryphe has joined #bitcoin-core-dev
 362019-03-08T03:11:24  *** schmidty has quit IRC
 372019-03-08T03:19:35  *** promag has joined #bitcoin-core-dev
 382019-03-08T03:23:47  *** promag has quit IRC
 392019-03-08T03:28:19  *** schmidty has joined #bitcoin-core-dev
 402019-03-08T03:28:34  *** elichai2 has quit IRC
 412019-03-08T03:32:51  *** schmidty has quit IRC
 422019-03-08T03:36:58  *** schmidty has joined #bitcoin-core-dev
 432019-03-08T03:41:46  *** schmidty has quit IRC
 442019-03-08T03:45:05  *** schmidty has joined #bitcoin-core-dev
 452019-03-08T03:49:37  *** schmidty has quit IRC
 462019-03-08T04:04:34  *** captjakk has joined #bitcoin-core-dev
 472019-03-08T04:08:44  *** captjakk has quit IRC
 482019-03-08T04:11:24  *** schmidty has joined #bitcoin-core-dev
 492019-03-08T04:15:58  *** schmidty has quit IRC
 502019-03-08T04:22:16  *** mn949588 has quit IRC
 512019-03-08T04:22:31  *** mn949588 has joined #bitcoin-core-dev
 522019-03-08T04:26:04  *** spinza has quit IRC
 532019-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?
 542019-03-08T04:30:32  *** bitcoin-git has joined #bitcoin-core-dev
 552019-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
 562019-03-08T04:30:33  *** bitcoin-git has left #bitcoin-core-dev
 572019-03-08T04:31:47  *** spinza has joined #bitcoin-core-dev
 582019-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
 592019-03-08T04:39:39  <gmaxwell> as in it only does it as part of the branch and bound analysis for changeless spends.
 602019-03-08T04:39:52  <gmaxwell> (that isn't the only case where it can spend extra inputs)
 612019-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)
 622019-03-08T04:41:20  <gmaxwell> depending on the specific case.
 632019-03-08T04:53:58  *** gxd has joined #bitcoin-core-dev
 642019-03-08T04:54:39  <gxd> hello everyone!
 652019-03-08T04:55:06  <gxd> nNce to meet you!
 662019-03-08T04:55:45  *** gxd has quit IRC
 672019-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
 682019-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
 692019-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
 702019-03-08T05:16:36  *** echeveria has quit IRC
 712019-03-08T05:16:42  <gmaxwell> shesek: IIRC bitcoin core has always violated it from day one. just not that all that often.
 722019-03-08T05:16:56  <sipa> i believe that's correct
 732019-03-08T05:16:56  *** echeveria has joined #bitcoin-core-dev
 742019-03-08T05:16:56  *** echeveria has joined #bitcoin-core-dev
 752019-03-08T05:17:31  *** echeveria has joined #bitcoin-core-dev
 762019-03-08T05:17:31  *** echeveria has joined #bitcoin-core-dev
 772019-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
 782019-03-08T05:18:40  <shesek> this leaves UIH due to MIN_CHANGE and low fees period? are there more potential causes?
 792019-03-08T05:20:35  *** hebasto has joined #bitcoin-core-dev
 802019-03-08T05:27:34  <gmaxwell> shesek: yes, coin selection can just pick extra inputs.
 812019-03-08T05:27:41  <gmaxwell> because the algorithim is probablistic.
 822019-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?
 832019-03-08T05:34:38  <shesek> what does your intuition tell you? would you expect them to be common? say, more common than 2%?
 842019-03-08T05:35:14  <shesek> (assuming spending all utxos of the same address is accounted for and not considered as uih)
 852019-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.
 862019-03-08T05:36:41  <gmaxwell> I'd be surprised if it happened more than a few percent of the time except w/ pathlogical wallets
 872019-03-08T05:36:53  <gmaxwell> oh well minchange makes it happen pretty often too
 882019-03-08T05:37:02  <shesek> so not so common on a typical wallet that receives payments about the same size as he sends
 892019-03-08T05:37:49  <shesek> minchange would also mostly kick into action with lots of tinyish inputs though, right?
 902019-03-08T05:38:25  <shesek> s/sends$/sends?/ (was meant as a question)
 912019-03-08T05:39:21  <gmaxwell> lots of small inputs is much more likely to find an exact (changeless) solution via branch and bound.
 922019-03-08T05:43:50  *** justanotheruser has quit IRC
 932019-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
 942019-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
 952019-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:
 962019-03-08T05:48:29  <gmaxwell> ./bitcoin-cli getpeerinfo | grep '^    "addr"'  | grep '[0-9]\.' | cut -d'"' -f4 | cut -d':' -f1  | sort | uniq
 972019-03-08T05:49:01  <shesek> but my intuition might be broken :) what do you think? is this a reasonable heuristic to point out?
 982019-03-08T05:49:12  <gmaxwell> shesek: bitcoin core manages to produce changeless payments quite often, so long as the wallet has many inputs.
 992019-03-08T05:51:27  *** DeanGuss has joined #bitcoin-core-dev
1002019-03-08T05:52:46  <shesek> what would you consider as many? thousands? hundreds? or even just a few dozens?
1012019-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
1022019-03-08T05:52:51  <gmaxwell> fees by, then there is probably a changeless solution, and bitcoin core will find it if there is one.
1032019-03-08T05:52:58  <gmaxwell> dozens works.
1042019-03-08T05:53:20  <sipa> it's much easier to find a changeless input selection when the feerate is high
1052019-03-08T05:53:54  <gmaxwell> I've seen it find changeless soluions in my own walle, which doesn' have that many inputs.
1062019-03-08T05:54:59  <shesek> I looked through my electrum history, couldn't spot a single changeless transaction except for manual coin selection ones
1072019-03-08T05:55:33  <sipa> i doubt electrum has bab
1082019-03-08T05:55:39  <gmaxwell> Weakling wallet software. :P
1092019-03-08T05:55:48  <gmaxwell> Lacks advanced science power.
1102019-03-08T05:55:49  <gmaxwell> :P
1112019-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?
1122019-03-08T05:57:12  <gmaxwell> shesek: pretty significant fraction of all, at least a year ago it was many times more than electrum.
1132019-03-08T05:57:36  <gmaxwell> electrum gets used by a lot of small indivigual users that don't transact frequenly...
1142019-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
1152019-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 :)
1162019-03-08T06:04:59  *** hebasto has quit IRC
1172019-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
1182019-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 :)
1192019-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.
1202019-03-08T06:09:44  <gmaxwell> how does the output type thing handle > 2 outputs?
1212019-03-08T06:12:36  *** schmidty has joined #bitcoin-core-dev
1222019-03-08T06:13:35  <shesek> it currently doesn't attempt to, its only applied to transactions with exactly two outputs
1232019-03-08T06:14:06  <gmaxwell> does it pay attention to input types at all for that?
1242019-03-08T06:15:11  <gmaxwell> also does it treat all p2sh as equal typed?
1252019-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
1262019-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.
1272019-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
1282019-03-08T06:16:50  *** schmidty has quit IRC
1292019-03-08T06:16:56  <gmaxwell> that hurestic will pretty reliably misidentify change for many bitcoin core users right now. :)
1302019-03-08T06:17:31  <shesek> oh really. how so?
1312019-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
1322019-03-08T06:18:29  <gmaxwell> core will match change type for p2sh vs native, but not legacy (unless overridden).
1332019-03-08T06:18:38  <shesek> ah, I see, interesting
1342019-03-08T06:19:35  <shesek> I didn't know core can be configured to match its change for payments to legacy scripts, very cool!
1352019-03-08T06:19:42  <gmaxwell> electrum made some odd decisions with segwit deployment, e.g. forcing wallets to be native segwit or not segwit
1362019-03-08T06:19:51  *** promag has joined #bitcoin-core-dev
1372019-03-08T06:20:24  <kallewoof> gmaxwell: I can send IP info from public node. How would you like it sent tho?
1382019-03-08T06:20:54  <gmaxwell> kallewoof: 0bin and an irc private message would be preferred.  or an email.
1392019-03-08T06:23:43  <kallewoof> sent
1402019-03-08T06:24:10  *** promag has quit IRC
1412019-03-08T06:24:37  <gmaxwell> kallewoof: thanks!
1422019-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?
1432019-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
1442019-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?
1452019-03-08T06:33:35  <gmaxwell> shesek: what matters more is how many inputs it has to choose from, not how many get used.
1462019-03-08T06:34:04  <shesek> how many got used is also important, no? more inputs allows you more combinations
1472019-03-08T06:34:21  <shesek> finding a combination of two utxos that matches the payment amount is harder than finding a combination of 4
1482019-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.
1492019-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.
1502019-03-08T06:37:53  <gmaxwell> which for taint analysis sorts of purposes is just a payment.
1512019-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)
1522019-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
1532019-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.
1542019-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.
1552019-03-08T06:44:38  <shesek> well, I'm open to listening and trying to find ways to improve it :)
1562019-03-08T06:44:59  *** d_t has quit IRC
1572019-03-08T06:45:12  *** d_t has joined #bitcoin-core-dev
1582019-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.
1592019-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
1602019-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
1612019-03-08T06:47:33  *** zhangzf has quit IRC
1622019-03-08T06:47:46  <gmaxwell> There is no 'send max' in many wallets.
1632019-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
1642019-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
1652019-03-08T06:48:09  *** zhangzf has joined #bitcoin-core-dev
1662019-03-08T06:48:11  <sipa> but if we're talking about multiple inputs... not so much
1672019-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
1682019-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.
1692019-03-08T06:48:34  *** hamma has joined #bitcoin-core-dev
1702019-03-08T06:49:12  <hamma> hello
1712019-03-08T06:49:19  <gmaxwell> shesek: FWIW 20% of the donations to me that I see are 1-in-1-out.
1722019-03-08T06:49:38  <hamma> anyone here
1732019-03-08T06:50:07  <gmaxwell> (maybe people emptying out wallets? dunno.)
1742019-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
1752019-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
1762019-03-08T06:52:17  *** hamma has quit IRC
1772019-03-08T06:54:13  *** harding has quit IRC
1782019-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
1792019-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
1802019-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.
1812019-03-08T06:56:04  <shesek> I would really love to run an analysis and get some numbers >_<
1822019-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".
1832019-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
1842019-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.
1852019-03-08T06:58:02  <shesek> yes, I definitely could, and turn off the "possibly self-transfer" message when that happens.
1862019-03-08T06:58:31  <gmaxwell> any incomplete spend ultimately hurts privacy, because its one of the main causes of taint snowballing.
1872019-03-08T06:58:51  <shesek> ah, I see, so an explicit message about not spending all available utxos in one go... yes, definitely :)
1882019-03-08T06:59:09  <shesek> noted!
1892019-03-08T06:59:46  <echeveria> shesek: my comment stands, really. just by seeing the message they leaked their own privacy.
1902019-03-08T07:00:28  <shesek> by visiting a public block explorer you mean?
1912019-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.
1922019-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".
1932019-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"
1942019-03-08T07:01:11  <shesek> echeveria, well, esplora is open-source, you could self-host it :)
1952019-03-08T07:01:11  <gmaxwell> yea, use of the explorer (or electrum in the first place) is a bigger privacy loss than "send max".
1962019-03-08T07:01:12  *** harding has joined #bitcoin-core-dev
1972019-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
1982019-03-08T07:02:01  <gmaxwell> just always display "privacy note: this address has been looked up on a public explorer" :P
1992019-03-08T07:02:02  <shesek> I've done this countless times
2002019-03-08T07:02:08  <sipa> shesek: sure, just don't include the warning in the open source version :)
2012019-03-08T07:02:27  <gmaxwell> just have a config flag, "public_explorer=1"
2022019-03-08T07:02:29  <gmaxwell> :P
2032019-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.
2042019-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
2052019-03-08T07:04:17  <sipa> shesek: you can't compars those things
2062019-03-08T07:04:27  <shesek> this is especially common around forkcoins selloffs
2072019-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.
2082019-03-08T07:04:53  <gmaxwell> it's more or less a total privacy loss.
2092019-03-08T07:04:56  <shesek> I'm running electrum with EPS and oneserver :)
2102019-03-08T07:05:11  <gmaxwell> okay you're weird. but you know that isn't true for more than a tiny percent of users. :)
2112019-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
2122019-03-08T07:05:42  <shesek> its not just an electrum thing
2132019-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.
2142019-03-08T07:06:15  <echeveria> more than that. just the simple act "someone is interested in this transaction" is insane information.
2152019-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
2162019-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
2172019-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.
2182019-03-08T07:06:51  <shesek> "send max" links all your wallet addresses together, on a public blockchain, for all ethernity
2192019-03-08T07:07:08  <sipa> shesek: but maybe they were already clearly linked together for other reasons
2202019-03-08T07:07:13  <echeveria> doesn't matter. the fact that someone cares at all about a transaction makes it hugely interesting.
2212019-03-08T07:07:51  <sipa> i am super happy that there is a decent explorer now for debugging stuff out there
2222019-03-08T07:08:18  <sipa> but i'm concerned about making it sound like it's an actual production tool
2232019-03-08T07:08:47  <sipa> i know people will use explorers, and one that gives good information is better than one that confuses everything
2242019-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 :)
2252019-03-08T07:09:06  <sipa> but really... we shouldn't encourage using the
2262019-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.
2272019-03-08T07:11:09  <gmaxwell> except when there just wasn't any linked history at all.
2282019-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...
2292019-03-08T07:11:43  <sipa> (only talking about widely used public instances here)
2302019-03-08T07:12:05  <shesek> gmaxwell, sorry, BNB?
2312019-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.
2322019-03-08T07:12:31  <sipa> shesek: branch and bound, the algorithm we use for changeless input selectio
2332019-03-08T07:13:07  <shesek> ah, okay. and what does cojoined siblings mean?
2342019-03-08T07:13:47  <shesek> like, outputs of the same transaction?
2352019-03-08T07:14:22  <shesek> probably not, because a user creating multiple outputs to himself in the same tx is quite unlikely
2362019-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)
2372019-03-08T07:14:56  <gmaxwell> (and there is a related hurestic that you can do if you identify change, but its far less reliable)
2382019-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.
2392019-03-08T07:15:25  <gmaxwell> A send-max will spend any spendable outputs to A-F.
2402019-03-08T07:15:39  *** rockhouse has joined #bitcoin-core-dev
2412019-03-08T07:15:42  *** victorSN has joined #bitcoin-core-dev
2422019-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.
2432019-03-08T07:16:32  <gmaxwell> it might be some kind of manual selection payment or a exact match payment.
2442019-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.
2452019-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
2462019-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
2472019-03-08T07:18:32  <echeveria> shesek: well, literally you. https://twitter.com/Excellion/status/1103614846468161537
2482019-03-08T07:19:49  <shesek> *literally* me? I'm pretty sure I'm not samson :p
2492019-03-08T07:20:12  <gmaxwell> shesek: it's quoting you.
2502019-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)
2512019-03-08T07:21:31  <shesek> gmaxwell, but I think he meant specifically the text by samson? my text says even less
2522019-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?
2532019-03-08T07:30:21  <shesek> I'm getting the feeling you're somewhat negative about all this, genuinely interested in understanding your position
2542019-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.
2552019-03-08T07:31:31  <shesek> the reason I came here asking for questions is exactly that care :)
2562019-03-08T07:31:32  <echeveria> first and permanent item on the list: you just messed up by ending up on this page.
2572019-03-08T07:32:21  <midnightmagic> :-/
2582019-03-08T07:32:32  <shesek> I do want to do this right and am very open to feedback
2592019-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.
2602019-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.
2612019-03-08T07:34:58  <gmaxwell> (so my advice there, submit patched to electrum/core/ga to provide the privacy notes :P )
2622019-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)
2632019-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)
2642019-03-08T07:36:24  <gmaxwell> I don't understand how UIH is privacy related at all.
2652019-03-08T07:36:36  <gmaxwell> I get that its a hurestic that electrum or whatever won't violate.
2662019-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"
2672019-03-08T07:37:52  <shesek> I can understand how it might not be effective, but how come they're not even related?
2682019-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, ..."
2692019-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.
2702019-03-08T07:38:45  <gmaxwell> There are much stronger identifers of the wallet software.
2712019-03-08T07:39:17  <sipa> tx version, anti fee sniping locktimes, low r grinding, ...
2722019-03-08T07:39:39  <gmaxwell> support for mixed sw and non-sw inputs. ability to pay to varrious output types, multisig...
2732019-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
2742019-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.
2752019-03-08T07:40:10  <gmaxwell> yea, that taint analsis thing was pretty much an rng. :P
2762019-03-08T07:40:30  <sipa> shesek: i agree that leaking what software you're using is a leak
2772019-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.
2782019-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
2792019-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)
2802019-03-08T07:42:11  <sipa> but saying "this transaction is identifiable as being produced by software X" is exactly right
2812019-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.
2822019-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.
2832019-03-08T07:43:11  <gmaxwell> But giving little warning dings instead is fuddy.
2842019-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.
2852019-03-08T07:45:39  <gmaxwell> which then prolongs it being an identifier, which is bad to whatever extent being identifyable is bad.
2862019-03-08T07:46:12  <gmaxwell> it also doesn't give a baseline.
2872019-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
2882019-03-08T07:47:31  <shesek> implement it will stand out in the transition period
2892019-03-08T07:48:01  *** d_t has quit IRC
2902019-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.
2912019-03-08T07:48:10  <shesek> it could perhaps be displayed differently, just as a note rather than a "warning" sort of thing
2922019-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"
2932019-03-08T07:49:25  <shesek> ugh, live
2942019-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"
2952019-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
2962019-03-08T07:50:34  <shesek> is there a % under which you would consider this a valid heuristic?
2972019-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.
2982019-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.
2992019-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?
3002019-03-08T07:55:06  <gmaxwell> no! because other properties of the transaction already identify the source software.
3012019-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
3022019-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"
3032019-03-08T07:57:36  <shesek> gmaxwell, do you think payjoin should not make an explicit effort to avoid triggering uih-2?
3042019-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.
3052019-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?"
3062019-03-08T07:58:34  <echeveria> fee rate rounding, output ordering, input ordering, utxo selection criteria.
3072019-03-08T07:59:19  <echeveria> huh?
3082019-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)
3092019-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)
3102019-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.
3112019-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.
3122019-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.
3132019-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.
3142019-03-08T08:05:06  <shesek> well, its not just a single criteria though, there are 7 now and I'm looking to add more
3152019-03-08T08:05:17  <shesek> how about if it looked less like a warning and more like informational text?
3162019-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.
3172019-03-08T08:06:14  <shesek> oh yes, can definitely identify weird script patterns and notify about them
3182019-03-08T08:06:47  <shesek> like, displaying a message if the script pattern is used by <X% of transactions sounds very reasonable to me
3192019-03-08T08:07:49  <gmaxwell> I think this is likely to hurt users by randomizing preferences.
3202019-03-08T08:07:52  <shesek> I mean, until we have taproot, using something like GA does have a very real privacy cost
3212019-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.
3222019-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
3232019-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.
3242019-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).
3252019-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
3262019-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?
3272019-03-08T08:13:10  *** schmidty has joined #bitcoin-core-dev
3282019-03-08T08:15:52  <gmaxwell> I'm exhausted by this conversation.
3292019-03-08T08:17:47  *** schmidty has quit IRC
3302019-03-08T08:18:24  *** Klox has quit IRC
3312019-03-08T08:18:40  *** jungly has joined #bitcoin-core-dev
3322019-03-08T08:19:08  *** Klox has joined #bitcoin-core-dev
3332019-03-08T08:19:20  *** promag has joined #bitcoin-core-dev
3342019-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
3352019-03-08T08:20:03  <gmaxwell> that aren't even visible from the transaction) that that would do users and the ecosystem a terrible disservice.
3362019-03-08T08:21:52  *** promag has quit IRC
3372019-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.)
3382019-03-08T08:22:45  *** promag has joined #bitcoin-core-dev
3392019-03-08T08:22:54  <gmaxwell> (either through the transactions or from network analytics)
3402019-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
3412019-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.
3422019-03-08T08:26:27  <gmaxwell> that aregument would be stronger if your coverage were actually even.
3432019-03-08T08:27:00  <shesek> even?
3442019-03-08T08:27:16  *** harding has quit IRC
3452019-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.
3462019-03-08T08:29:08  *** harding has joined #bitcoin-core-dev
3472019-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
3482019-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 :)
3492019-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.
3502019-03-08T08:34:24  <gmaxwell> (you can also see that period on graphs of the utxo set size. :( )
3512019-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
3522019-03-08T08:40:01  <shesek> I'm not here to develop sophisticated spying tools :)
3532019-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
3542019-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.
3552019-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.
3562019-03-08T08:42:51  <gmaxwell> and a metric of how common that pattern is like the panopticlick metrics.
3572019-03-08T08:43:25  <gmaxwell> which would be more useful for user in seeing privacy levels but less useful for tracking particular people.
3582019-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.
3592019-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.
3602019-03-08T08:45:48  <shesek> what is the oo in oorbf?
3612019-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)
3622019-03-08T08:47:59  <gmaxwell> bitcoin core can but its a setting.
3632019-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.
3642019-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.
3652019-03-08T08:51:09  *** cornfeedhobo has quit IRC
3662019-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
3672019-03-08T08:51:27  <shesek> * rbf
3682019-03-08T08:52:16  <gmaxwell> oo was inteded to be oi -- the keys are next to each other on qwerty. Sorry. :P
3692019-03-08T08:52:34  <gmaxwell> (or maybe I was thinking opt-out who knows)
3702019-03-08T08:53:03  <shesek> oh okay :)
3712019-03-08T08:54:33  *** fanquake has quit IRC
3722019-03-08T08:55:09  *** cornfeedhobo has joined #bitcoin-core-dev
3732019-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
3742019-03-08T08:56:01  <shesek> even if its based just on public data, I still feel the line can be crossed
3752019-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.
3762019-03-08T08:57:09  <gmaxwell> stats on well known data is something I can go on freelancer and pay someone to do though.
3772019-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
3782019-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
3792019-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
3802019-03-08T09:06:53  <gmaxwell> no, I don't think the data being public is the line.
3812019-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
3822019-03-08T09:07:07  *** anome has joined #bitcoin-core-dev
3832019-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.
3842019-03-08T09:08:02  *** anome has quit IRC
3852019-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
3862019-03-08T09:08:26  <gmaxwell> Right.
3872019-03-08T09:08:27  <shesek> I guess this could be a good line
3882019-03-08T09:08:40  <wumpus> and you never know that
3892019-03-08T09:08:59  <wumpus> if you can think of it, someone at the NSA probably thought of it too
3902019-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.
3912019-03-08T09:10:17  *** smarti has joined #bitcoin-core-dev
3922019-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.
3932019-03-08T09:10:45  <gmaxwell> the commercial anti-privacy services seem to have kind of mixed competence.
3942019-03-08T09:11:01  *** anome has joined #bitcoin-core-dev
3952019-03-08T09:11:43  <gmaxwell> like I can imagine that some have never realized you could use UIH to distinguish some wallet software.
3962019-03-08T09:12:03  <wumpus> that's definitely true
3972019-03-08T09:12:08  *** mmgen has joined #bitcoin-core-dev
3982019-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. :)
3992019-03-08T09:13:20  <gmaxwell> I've typed a couple other things here and erased them to not give people ideas. :P
4002019-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
4012019-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"
4022019-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.
4032019-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
4042019-03-08T09:16:52  *** anome has quit IRC
4052019-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
4062019-03-08T09:19:05  <shesek> and some of the texts could use some corrections/clarification
4072019-03-08T09:23:36  *** fanquake has joined #bitcoin-core-dev
4082019-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 :)
4092019-03-08T09:29:07  *** timothy has joined #bitcoin-core-dev
4102019-03-08T09:30:52  *** owowo has quit IRC
4112019-03-08T09:31:26  *** promag_ has joined #bitcoin-core-dev
4122019-03-08T09:35:52  *** owowo has joined #bitcoin-core-dev
4132019-03-08T09:40:34  *** setpill has joined #bitcoin-core-dev
4142019-03-08T09:47:01  *** jonatack_ has joined #bitcoin-core-dev
4152019-03-08T09:47:03  *** anome has joined #bitcoin-core-dev
4162019-03-08T09:50:12  *** anome has quit IRC
4172019-03-08T09:51:35  *** jonatack_ has quit IRC
4182019-03-08T10:03:37  *** kexkey has quit IRC
4192019-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.
4202019-03-08T10:09:03  *** mmgen has quit IRC
4212019-03-08T10:11:27  <fanquake> I guess related to #14561
4222019-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
4232019-03-08T10:11:39  *** promag has quit IRC
4242019-03-08T10:11:53  *** mmgen has joined #bitcoin-core-dev
4252019-03-08T10:12:19  *** promag has joined #bitcoin-core-dev
4262019-03-08T10:14:27  *** schmidty has joined #bitcoin-core-dev
4272019-03-08T10:18:45  *** schmidty has quit IRC
4282019-03-08T10:22:32  *** smarti has quit IRC
4292019-03-08T10:22:42  *** fuqaiq has joined #bitcoin-core-dev
4302019-03-08T10:23:58  *** fuqaiq has quit IRC
4312019-03-08T10:29:49  *** vexbuy has joined #bitcoin-core-dev
4322019-03-08T10:32:17  *** vexbuy has quit IRC
4332019-03-08T10:34:41  *** anome has joined #bitcoin-core-dev
4342019-03-08T10:35:02  *** anome has quit IRC
4352019-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.
4362019-03-08T10:37:29  <gmaxwell> Should it be a goal for 0.19? 0.20?
4372019-03-08T10:38:02  <gmaxwell> Bitcoin core makes it pretty easy to get other addresses when you need them for compatiblity, fortunately.
4382019-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.
4392019-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.
4402019-03-08T10:40:12  <gmaxwell> But maybe announcing a plan to default by version X might help some parties prioritize.
4412019-03-08T10:46:13  *** anome has joined #bitcoin-core-dev
4422019-03-08T10:48:55  *** anome has quit IRC
4432019-03-08T10:49:13  *** anome has joined #bitcoin-core-dev
4442019-03-08T10:49:46  *** anome has quit IRC
4452019-03-08T10:49:57  *** zhangzf has quit IRC
4462019-03-08T10:51:59  *** schmidty has joined #bitcoin-core-dev
4472019-03-08T10:52:32  *** timothy has quit IRC
4482019-03-08T10:56:35  *** schmidty has quit IRC
4492019-03-08T11:00:03  *** spinza has quit IRC
4502019-03-08T11:11:18  *** Victorsueca has quit IRC
4512019-03-08T11:12:06  *** Victorsueca has joined #bitcoin-core-dev
4522019-03-08T11:19:06  *** spinza has joined #bitcoin-core-dev
4532019-03-08T11:23:57  *** schmidty has joined #bitcoin-core-dev
4542019-03-08T11:23:57  *** schmidty has joined #bitcoin-core-dev
4552019-03-08T11:24:15  *** timothy has joined #bitcoin-core-dev
4562019-03-08T11:27:03  *** AaronvanW has joined #bitcoin-core-dev
4572019-03-08T11:37:32  *** owowo has quit IRC
4582019-03-08T11:38:33  *** owowo has joined #bitcoin-core-dev
4592019-03-08T11:51:03  *** anome has joined #bitcoin-core-dev
4602019-03-08T12:23:18  <instagibbs> a hotter take would be to make segwit v1 unenforced inside p2sh
4612019-03-08T12:24:05  <instagibbs> bad idea for money-loss reasons :)
4622019-03-08T12:26:59  *** anome has quit IRC
4632019-03-08T12:28:24  *** anome has joined #bitcoin-core-dev
4642019-03-08T12:30:50  <gmaxwell> I dunno if it would be likely to result in money loss.
4652019-03-08T12:31:05  <gmaxwell> There is a fine line between encouragement and arm bending though.
4662019-03-08T12:31:24  <gmaxwell> if it's taking e.g. ledger >1 year to add support, maybe more encouragement is required.
4672019-03-08T12:43:08  *** Aaronvan_ has joined #bitcoin-core-dev
4682019-03-08T12:46:05  <fanquake> fwiw i opened #15560 for discussion
4692019-03-08T12:46:06  <gribble> https://github.com/bitcoin/bitcoin/issues/15560 | When to make bech32 the default -addresstype? · Issue #15560 · bitcoin/bitcoin · GitHub
4702019-03-08T12:46:24  *** AaronvanW has quit IRC
4712019-03-08T12:58:49  <luke-jr> IMO making segwit v1 unenforced inside p2sh is more of bludgeoning than arm bending :P
4722019-03-08T12:59:58  <luke-jr> (policy rejection might be more like arm bending)
4732019-03-08T13:03:03  *** jonatack has joined #bitcoin-core-dev
4742019-03-08T13:06:45  *** promag_ has quit IRC
4752019-03-08T13:13:03  *** hex17or has quit IRC
4762019-03-08T13:18:22  *** Skirmant has quit IRC
4772019-03-08T13:20:56  *** spaced0ut has joined #bitcoin-core-dev
4782019-03-08T13:35:45  *** setpill has quit IRC
4792019-03-08T13:38:57  *** captjakk has joined #bitcoin-core-dev
4802019-03-08T13:43:25  *** captjakk has quit IRC
4812019-03-08T13:52:35  *** tryphe has quit IRC
4822019-03-08T13:53:01  *** tryphe has joined #bitcoin-core-dev
4832019-03-08T13:55:27  *** Aaronvan_ is now known as AaronvanW
4842019-03-08T14:13:37  *** bitcoin-git has joined #bitcoin-core-dev
4852019-03-08T14:13:37  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d211edb34982...923d87497c7c
4862019-03-08T14:13:38  <bitcoin-git> bitcoin/master fa58a2e MarcoFalke: contrib: Bump gitian descriptors for 0.19
4872019-03-08T14:13:38  <bitcoin-git> bitcoin/master 923d874 MarcoFalke: Merge #15528: contrib: Bump gitian descriptors for 0.19
4882019-03-08T14:13:40  *** bitcoin-git has left #bitcoin-core-dev
4892019-03-08T14:14:20  *** bitcoin-git has joined #bitcoin-core-dev
4902019-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
4912019-03-08T14:14:25  *** bitcoin-git has left #bitcoin-core-dev
4922019-03-08T14:20:06  *** Skirmant has joined #bitcoin-core-dev
4932019-03-08T14:26:53  *** bitcoin-git has joined #bitcoin-core-dev
4942019-03-08T14:26:53  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/923d87497c7c...efed9809b4fa
4952019-03-08T14:26:53  <bitcoin-git> bitcoin/master 82c3b3f practicalswift: Remove sharp edge (uninitialized m_filter_type) when using the compiler-ge...
4962019-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...
4972019-03-08T14:26:56  *** bitcoin-git has left #bitcoin-core-dev
4982019-03-08T14:27:33  *** bitcoin-git has joined #bitcoin-core-dev
4992019-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
5002019-03-08T14:27:45  *** bitcoin-git has left #bitcoin-core-dev
5012019-03-08T14:35:02  *** Guyver2 has joined #bitcoin-core-dev
5022019-03-08T14:43:53  *** promag has quit IRC
5032019-03-08T14:44:07  *** promag has joined #bitcoin-core-dev
5042019-03-08T14:49:29  *** promag_ has joined #bitcoin-core-dev
5052019-03-08T14:49:29  *** promag has quit IRC
5062019-03-08T15:17:35  *** hex17or has joined #bitcoin-core-dev
5072019-03-08T15:18:40  *** hex17or has quit IRC
5082019-03-08T15:19:36  *** hex17or has joined #bitcoin-core-dev
5092019-03-08T15:21:15  *** jonatack has quit IRC
5102019-03-08T15:23:37  *** hebasto has joined #bitcoin-core-dev
5112019-03-08T15:24:57  *** zhangzf has joined #bitcoin-core-dev
5122019-03-08T15:31:16  *** anome has quit IRC
5132019-03-08T15:38:17  *** cubancorona has quit IRC
5142019-03-08T15:38:38  *** cubancorona has joined #bitcoin-core-dev
5152019-03-08T15:39:53  *** hebasto has quit IRC
5162019-03-08T15:43:13  *** asdfgarev has joined #bitcoin-core-dev
5172019-03-08T16:05:05  *** jarthur has joined #bitcoin-core-dev
5182019-03-08T16:06:07  *** AaronvanW has quit IRC
5192019-03-08T16:06:42  *** AaronvanW has joined #bitcoin-core-dev
5202019-03-08T16:09:44  *** elichai2 has joined #bitcoin-core-dev
5212019-03-08T16:21:33  *** Soligor has joined #bitcoin-core-dev
5222019-03-08T16:34:03  *** zhangzf has quit IRC
5232019-03-08T16:36:10  *** Guyver2 has quit IRC
5242019-03-08T16:36:47  *** Guyver2 has joined #bitcoin-core-dev
5252019-03-08T16:48:17  *** tryphe has quit IRC
5262019-03-08T16:48:28  *** promag_ has quit IRC
5272019-03-08T16:48:47  *** tryphe has joined #bitcoin-core-dev
5282019-03-08T16:49:00  *** promag has joined #bitcoin-core-dev
5292019-03-08T17:03:06  *** spinza has quit IRC
5302019-03-08T17:07:10  *** Bullit has quit IRC
5312019-03-08T17:07:51  *** jungly has quit IRC
5322019-03-08T17:12:24  *** Bullit has joined #bitcoin-core-dev
5332019-03-08T17:13:55  *** spinza has joined #bitcoin-core-dev
5342019-03-08T17:28:00  *** ap4lmtree has quit IRC
5352019-03-08T17:28:22  *** ap4lmtree has joined #bitcoin-core-dev
5362019-03-08T17:48:19  *** tryphe has quit IRC
5372019-03-08T17:48:46  *** tryphe has joined #bitcoin-core-dev
5382019-03-08T17:49:13  *** qrestlove has joined #bitcoin-core-dev
5392019-03-08T17:50:19  *** promag_ has joined #bitcoin-core-dev
5402019-03-08T17:56:35  *** Deinogalerix21 has joined #bitcoin-core-dev
5412019-03-08T18:02:26  *** anome has joined #bitcoin-core-dev
5422019-03-08T18:06:32  *** Deinogalerix21 has quit IRC
5432019-03-08T18:17:38  *** promag_ has quit IRC
5442019-03-08T18:30:03  *** IGHOR has quit IRC
5452019-03-08T18:31:14  *** IGHOR has joined #bitcoin-core-dev
5462019-03-08T18:33:46  *** anome has quit IRC
5472019-03-08T18:39:10  *** anome has joined #bitcoin-core-dev
5482019-03-08T18:42:55  *** pinheadmz has quit IRC
5492019-03-08T18:43:29  *** anome has quit IRC
5502019-03-08T18:43:31  *** timothy has quit IRC
5512019-03-08T18:48:23  *** shesek has quit IRC
5522019-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
5532019-03-08T18:50:45  *** pinheadmz has joined #bitcoin-core-dev
5542019-03-08T18:54:33  *** anome has joined #bitcoin-core-dev
5552019-03-08T18:58:52  *** jonatack_ has joined #bitcoin-core-dev
5562019-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?
5572019-03-08T19:02:11  <gmaxwell> Uh, instrument a node and see if anyone is using it now?
5582019-03-08T19:02:42  <gmaxwell> (I'm not saying now, but even knowing when would require knowing what use is now)
5592019-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.
5602019-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(?!)
5612019-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.
5622019-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.
5632019-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)
5642019-03-08T19:05:49  *** anome has quit IRC
5652019-03-08T19:06:49  *** anome has joined #bitcoin-core-dev
5662019-03-08T19:08:51  *** pinheadmz has quit IRC
5672019-03-08T19:10:58  *** anome has quit IRC
5682019-03-08T19:13:16  *** anome has joined #bitcoin-core-dev
5692019-03-08T19:14:59  *** rex4539 has quit IRC
5702019-03-08T19:16:11  *** rex4539 has joined #bitcoin-core-dev
5712019-03-08T19:17:22  *** anome has quit IRC
5722019-03-08T19:18:29  *** rex4539 has joined #bitcoin-core-dev
5732019-03-08T19:24:21  *** millerti has joined #bitcoin-core-dev
5742019-03-08T19:24:41  *** promag_ has joined #bitcoin-core-dev
5752019-03-08T19:28:58  *** promag_ has quit IRC
5762019-03-08T19:35:38  *** pinheadmz has joined #bitcoin-core-dev
5772019-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
5782019-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
5792019-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
5802019-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
5812019-03-08T19:43:56  <sdaftuar> i also notice plenty of other normal-looking traffic from that peer (inv, cmpctblocks, headers, etc)
5822019-03-08T19:44:57  <pinheadmz> when I test against Bitcoin Core, I noticed Core sent getheaders first, then getdata for the actual blocks
5832019-03-08T19:45:21  <sdaftuar> yes, that makes sense to me
5842019-03-08T19:45:33  <pinheadmz> bcoin does support compact blocks, why is that a (?!) :-)
5852019-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
5862019-03-08T19:46:41  <sdaftuar> so i would have assumed anyone implemented compact blocks would have swithced to getheaders
5872019-03-08T19:47:35  *** anome has joined #bitcoin-core-dev
5882019-03-08T19:47:41  *** tryphe has quit IRC
5892019-03-08T19:48:07  *** tryphe has joined #bitcoin-core-dev
5902019-03-08T19:48:32  *** jcorgan has joined #bitcoin-core-dev
5912019-03-08T19:48:52  *** shesek has joined #bitcoin-core-dev
5922019-03-08T19:48:52  *** shesek has joined #bitcoin-core-dev
5932019-03-08T19:48:59  <sdaftuar> pinheadmz: any idea why bcoin still uses getblocks? sounds like you are saying that sometimes it uses getheaders instead?
5942019-03-08T19:49:55  *** anome has quit IRC
5952019-03-08T19:51:23  *** anome has joined #bitcoin-core-dev
5962019-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.
5972019-03-08T19:51:37  *** jcorgan_ has quit IRC
5982019-03-08T19:51:41  <pinheadmz> Actually Im curious why Core sends `getheaders` first, an then requests the full blocks?
5992019-03-08T19:51:59  <sipa> pinheadmz: how would it know what blocks to fetch?
6002019-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.
6012019-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
6022019-03-08T19:52:25  <pinheadmz> from `inv`
6032019-03-08T19:52:33  <pinheadmz> makes sense
6042019-03-08T19:52:39  <sipa> pinheadmz: that's only for newly mined blocks
6052019-03-08T19:52:49  <sipa> (or in response to getblocks...)
6062019-03-08T19:53:13  <sipa> and with BIP130, new blocks are also announced using headers instead of invs
6072019-03-08T19:53:30  <sipa> but that's optionally negotiated between peers
6082019-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)
6092019-03-08T19:54:19  <gmaxwell> pinheadmz: a header is not much larger than an INV but radically more useful.
6102019-03-08T19:54:33  <gmaxwell> pinheadmz: so essentially for blocks we'd replaced INVs with headers.
6112019-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
6122019-03-08T19:55:02  <pinheadmz> gmaxwell: ok thanks I see this now. SO `getheaders` asks the peer to just send headers without an `inv`
6132019-03-08T19:55:18  <pinheadmz> same behavior with SPV wallets
6142019-03-08T19:55:18  <sipa> pinheadmz: it sends headers instead of inv
6152019-03-08T19:55:24  <gmaxwell> pinheadmz: yes, its pretty much exactly like getblocks but sends headers.
6162019-03-08T19:55:29  *** ap4lmtree has quit IRC
6172019-03-08T19:55:47  <pinheadmz> then headers are verified, then `getdata` with block hashses
6182019-03-08T19:55:53  <sdaftuar> right
6192019-03-08T19:55:56  <sipa> right
6202019-03-08T19:56:00  <gmaxwell> right
6212019-03-08T19:56:16  <sipa> bitcoin core since 0.10 uses this as synchronization mechanism; it's called headers-first sync
6222019-03-08T19:56:36  <tryphe> how were blocks gotten before getheaders again? just block #? the new way has much better performance
6232019-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.
6242019-03-08T19:57:35  <sipa> tryphe: getblocks -> inv -> getdata -> block
6252019-03-08T19:57:56  <sipa> getblocks takes a locator and a count, and responds with an inv announcing the next count block hashesd
6262019-03-08T19:58:16  *** anome has quit IRC
6272019-03-08T19:58:17  <sipa> iirc
6282019-03-08T19:58:28  <sipa> the protocol doesn't expose anything by height
6292019-03-08T19:58:41  <sipa> as height is ambiguous in the presence of brances
6302019-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 :)
6312019-03-08T19:59:27  *** shesek has quit IRC
6322019-03-08T20:01:17  <pinheadmz> thanks guys, going to get the team on BIP130
6332019-03-08T20:01:39  <sipa> bip130 is a step being headers-first sync
6342019-03-08T20:01:43  <sipa> *beyond
6352019-03-08T20:02:23  <pinheadmz> is there a spec for headers first sync? (besides, this chat :-) which i think is pretty clear)
6362019-03-08T20:02:31  <gmaxwell> sdaftuar: yea, when you said you wanted to remove it that was what I assumed you wanted to remove.
6372019-03-08T20:02:31  <sdaftuar> (in particular it sounds like bcoin already implements bip 152, which is a step beyond bip 130.)
6382019-03-08T20:02:32  *** pinheadmz has left #bitcoin-core-dev
6392019-03-08T20:02:55  <sipa> kthxbye
6402019-03-08T20:03:03  *** Bullit has quit IRC
6412019-03-08T20:03:22  *** pinheadmz has joined #bitcoin-core-dev
6422019-03-08T20:03:45  <sipa> pinheadmz: no, not a spec - it's just a way of doing things, not really a protocol
6432019-03-08T20:03:52  <sipa> (it didn't need any changes to the p2p protocol)
6442019-03-08T20:04:09  <pinheadmz> will `getblocks` ever be unsupported?
6452019-03-08T20:04:13  <sipa> as getheaders/headers existed for years before we started using it for block syncing
6462019-03-08T20:04:28  <gmaxwell> pinheadmz: that was the subject of discussion.
6472019-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?
6482019-03-08T20:04:41  <sipa> sdaftuar: seems premature at this point
6492019-03-08T20:04:44  <sdaftuar> sipa: yeah
6502019-03-08T20:05:03  <gmaxwell> sdaftuar: maybe wait a bit so we don't waste time with 'bcoin' objecting, at least.
6512019-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
6522019-03-08T20:05:31  <gmaxwell> unfortunate to have to keep around the feeding hack.
6532019-03-08T20:05:53  <gmaxwell> sdaftuar: yes, thats fair, and something we should do.
6542019-03-08T20:06:19  <sdaftuar> pinheadmz: thanks for jumping on here to discuss
6552019-03-08T20:06:49  <pinheadmz> thanks for bringing it up!
6562019-03-08T20:06:55  *** Squidicuz has quit IRC
6572019-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).
6582019-03-08T20:44:33  *** mmgen has quit IRC
6592019-03-08T20:51:03  *** EagleTM has joined #bitcoin-core-dev
6602019-03-08T20:56:42  *** booyah has quit IRC
6612019-03-08T20:56:44  *** nullptr| has quit IRC
6622019-03-08T20:57:31  *** booyah has joined #bitcoin-core-dev
6632019-03-08T21:01:12  *** nullptr| has joined #bitcoin-core-dev
6642019-03-08T21:04:06  *** pinheadmz has quit IRC
6652019-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
6662019-03-08T21:04:26  *** pinheadmz has joined #bitcoin-core-dev
6672019-03-08T21:05:03  <sipa> for 1 sig/tx: 3.4% above 1/2
6682019-03-08T21:05:17  <sipa> for 2 sig/tx: 4.9% above 1/4
6692019-03-08T21:05:29  <sipa> for 3 sig/tx: 8.6% above 1/8
6702019-03-08T21:05:45  *** Aaronvan_ has joined #bitcoin-core-dev
6712019-03-08T21:06:10  <sipa> for 4 sig/tx: 7.2% above 1/16
6722019-03-08T21:06:38  <sipa> for 5 sig/tx: 11.6% abive 1/32
6732019-03-08T21:06:46  <sipa> for 6 sig/tx: 5% above 1/64
6742019-03-08T21:06:57  <sipa> for 7 sig/tx: 10.9% above 1/128
6752019-03-08T21:08:03  <gmaxwell> why are you changing the threshold and number of sigs?
6762019-03-08T21:09:12  *** AaronvanW has quit IRC
6772019-03-08T21:10:47  *** AaronvanW has joined #bitcoin-core-dev
6782019-03-08T21:13:40  *** ap4lmtree has joined #bitcoin-core-dev
6792019-03-08T21:13:47  *** Aaronvan_ has quit IRC
6802019-03-08T21:13:48  *** promag has quit IRC
6812019-03-08T21:14:04  *** promag has joined #bitcoin-core-dev
6822019-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
6832019-03-08T21:15:57  <gmaxwell> oh I thought that was the definition of lowness. :)
6842019-03-08T21:16:39  <sipa> gmaxwell: oh, i see my statement may be misinterpreted
6852019-03-08T21:17:06  <sipa> i mean for 5 sig/tx, (11.6% + 1/32) of transactions are fully lowr
6862019-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.
6872019-03-08T21:25:59  *** Guyver2 has quit IRC
6882019-03-08T21:26:46  <echeveria> sipa: I'd expect that really.
6892019-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.
6902019-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.
6912019-03-08T21:29:30  <echeveria> there's a very small number of 1 of 1 P2SH transactions too.
6922019-03-08T21:29:43  <gmaxwell> the coinjoin bounty fund is a mixed compressed multisig.
6932019-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.
6942019-03-08T21:32:49  *** Aaronvan_ has joined #bitcoin-core-dev
6952019-03-08T21:33:10  *** promag has quit IRC
6962019-03-08T21:33:46  *** promag has joined #bitcoin-core-dev
6972019-03-08T21:35:47  *** jarthur has quit IRC
6982019-03-08T21:35:53  *** AaronvanW has quit IRC
6992019-03-08T21:43:57  *** tryphe has quit IRC
7002019-03-08T21:44:21  *** tryphe has joined #bitcoin-core-dev
7012019-03-08T21:51:45  *** afk11 has quit IRC
7022019-03-08T21:55:54  *** spinza has quit IRC
7032019-03-08T22:02:44  *** dviola has joined #bitcoin-core-dev
7042019-03-08T22:03:35  *** promag_ has joined #bitcoin-core-dev
7052019-03-08T22:04:57  *** promag_ has quit IRC
7062019-03-08T22:05:30  *** Squidicuz has joined #bitcoin-core-dev
7072019-03-08T22:06:05  *** spinza has joined #bitcoin-core-dev
7082019-03-08T22:23:08  *** pso47 has joined #bitcoin-core-dev
7092019-03-08T22:25:53  *** promag_ has joined #bitcoin-core-dev
7102019-03-08T22:30:03  *** promag_ has quit IRC
7112019-03-08T22:52:01  *** spinza has quit IRC
7122019-03-08T22:52:03  *** EagleTM has quit IRC
7132019-03-08T22:59:59  *** spinza has joined #bitcoin-core-dev
7142019-03-08T23:05:38  *** belcher has quit IRC
7152019-03-08T23:08:06  *** justanotheruser has joined #bitcoin-core-dev
7162019-03-08T23:18:45  *** belcher has joined #bitcoin-core-dev
7172019-03-08T23:23:23  *** elichai2 has quit IRC
7182019-03-08T23:26:22  *** promag_ has joined #bitcoin-core-dev
7192019-03-08T23:43:08  *** AaronvanW has joined #bitcoin-core-dev
7202019-03-08T23:45:56  *** Aaronvan_ has quit IRC
7212019-03-08T23:57:10  *** Aaronvan_ has joined #bitcoin-core-dev
7222019-03-08T23:58:11  *** pso47 has quit IRC