--- Log opened Fri Mar 08 00:00:10 2019 00:00 < 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) 00:01 < gmaxwell> And also avoiding UIH-2 normatively would almost certantly be a mistake, since as wallets improve more will violate it. 00:03 < 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. 00:03 < 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. 00:04 < 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. 00:05 < shesek> well, its not just a single criteria though, there are 7 now and I'm looking to add more 00:05 < shesek> how about if it looked less like a warning and more like informational text? 00:05 < 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. 00:06 < shesek> oh yes, can definitely identify weird script patterns and notify about them 00:06 < shesek> like, displaying a message if the script pattern is used by I think this is likely to hurt users by randomizing preferences. 00:07 < shesek> I mean, until we have taproot, using something like GA does have a very real privacy cost 00:08 < 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. 00:09 < 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 00:09 < 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. 00:10 < 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). 00:11 < 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 00:12 < 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? 00:13 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev 00:15 < gmaxwell> I'm exhausted by this conversation. 00:17 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 240 seconds] 00:18 -!- Klox [~Klox@c-73-22-66-195.hsd1.il.comcast.net] has quit [Quit: Ping timeout (120 seconds)] 00:18 -!- jungly [~quassel@79.8.200.97] has joined #bitcoin-core-dev 00:19 -!- Klox [~Klox@c-73-22-66-195.hsd1.il.comcast.net] has joined #bitcoin-core-dev 00:19 -!- promag [~promag@bl23-83-33.dsl.telepac.pt] has joined #bitcoin-core-dev 00:20 < 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 00:20 < gmaxwell> that aren't even visible from the transaction) that that would do users and the ecosystem a terrible disservice. 00:21 -!- promag [~promag@bl23-83-33.dsl.telepac.pt] has quit [Remote host closed the connection] 00:22 < 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.) 00:22 -!- promag [~promag@bl23-83-33.dsl.telepac.pt] has joined #bitcoin-core-dev 00:22 < gmaxwell> (either through the transactions or from network analytics) 00:25 < 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 00:25 < 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. 00:26 < gmaxwell> that aregument would be stronger if your coverage were actually even. 00:27 < shesek> even? 00:27 -!- harding [~quassel@li1258-130.members.linode.com] has quit [Ping timeout: 250 seconds] 00:27 < 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. 00:29 -!- harding [~quassel@li1258-130.members.linode.com] has joined #bitcoin-core-dev 00:29 < 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 00:32 < 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 :) 00:34 < gmaxwell> You might want to look over time, you may see the release when bitcoin core wouldn't violate UIH-2. 00:34 < gmaxwell> (you can also see that period on graphs of the utxo set size. :( ) 00:39 < 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 00:40 < shesek> I'm not here to develop sophisticated spying tools :) 00:40 < 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 00:41 < 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. 00:42 < 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. 00:42 < gmaxwell> and a metric of how common that pattern is like the panopticlick metrics. 00:43 < gmaxwell> which would be more useful for user in seeing privacy levels but less useful for tracking particular people. 00:43 < gmaxwell> and also easier to maintain, as you don't need to go looking at how wallet work and how they change over time. 00:45 < 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. 00:45 < shesek> what is the oo in oorbf? 00:47 < 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) 00:47 < gmaxwell> bitcoin core can but its a setting. 00:49 < 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. 00:50 < 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. 00:51 -!- cornfeedhobo [~cornfeedh@unaffiliated/cornfeed] has quit [Quit: ZNC - https://znc.in] 00:51 < 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 00:51 < shesek> * rbf 00:52 < gmaxwell> oo was inteded to be oi -- the keys are next to each other on qwerty. Sorry. :P 00:52 < gmaxwell> (or maybe I was thinking opt-out who knows) 00:53 < shesek> oh okay :) 00:54 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [] 00:55 -!- cornfeedhobo [~cornfeedh@unaffiliated/cornfeed] has joined #bitcoin-core-dev 00:55 < 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 00:56 < shesek> even if its based just on public data, I still feel the line can be crossed 00:56 < 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. 00:57 < gmaxwell> stats on well known data is something I can go on freelancer and pay someone to do though. 01:00 < 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 01:01 < 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 01:03 < shesek> maybe easier to think about this as "overall negative or positive effect on bitcoin users' privacy" than in morality terms 01:06 < gmaxwell> no, I don't think the data being public is the line. 01:06 < 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 01:07 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev 01:07 < 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. 01:08 -!- anome [~anome@unaffiliated/anome] has quit [Client Quit] 01:08 < shesek> right, so no state-of-the-art stuff, only things you believe are likely already being done by component companies 01:08 < gmaxwell> Right. 01:08 < shesek> I guess this could be a good line 01:08 < wumpus> and you never know that 01:08 < wumpus> if you can think of it, someone at the NSA probably thought of it too 01:09 < 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. 01:10 -!- smarti [~gruqds@fs-93-93-44-38.fullsave.info] has joined #bitcoin-core-dev 01:10 < 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. 01:10 < gmaxwell> the commercial anti-privacy services seem to have kind of mixed competence. 01:11 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev 01:11 < gmaxwell> like I can imagine that some have never realized you could use UIH to distinguish some wallet software. 01:12 < wumpus> that's definitely true 01:12 -!- mmgen [~mmgen@gateway/tor-sasl/mmgen] has joined #bitcoin-core-dev 01:12 < 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. :) 01:13 < gmaxwell> I've typed a couple other things here and erased them to not give people ideas. :P 01:13 < 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 01:14 < 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" 01:14 < 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. 01:16 < 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 01:16 -!- anome [~anome@unaffiliated/anome] has quit [] 01:17 < 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 01:19 < shesek> and some of the texts could use some corrections/clarification 01:23 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 01:26 < 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 :) 01:29 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev 01:30 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 245 seconds] 01:31 -!- promag_ [~promag@195.54.168.134] has joined #bitcoin-core-dev 01:35 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 01:40 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev 01:47 -!- jonatack_ [6d0d4c36@gateway/web/freenode/ip.109.13.76.54] has joined #bitcoin-core-dev 01:47 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev 01:50 -!- anome [~anome@unaffiliated/anome] has quit [Client Quit] 01:51 -!- jonatack_ [6d0d4c36@gateway/web/freenode/ip.109.13.76.54] has quit [Ping timeout: 256 seconds] 02:03 -!- kexkey [~kexkey@68.168.122.228] has quit [Read error: Connection reset by peer] 02:08 < fanquake> At least one issue reported for rc1 so far, https://github.com/bitcoin/bitcoin/issues/15555#issuecomment-470827939, although need more info. 02:09 -!- mmgen [~mmgen@gateway/tor-sasl/mmgen] has quit [Quit: (https://github.com/mmgen) leaving] 02:11 < fanquake> I guess related to #14561 02:11 < gribble> https://github.com/bitcoin/bitcoin/issues/14561 | Remove fs::relative call and fix listwalletdir tests by promag · Pull Request #14561 · bitcoin/bitcoin · GitHub 02:11 -!- promag [~promag@bl23-83-33.dsl.telepac.pt] has quit [Remote host closed the connection] 02:11 -!- mmgen [~mmgen@gateway/tor-sasl/mmgen] has joined #bitcoin-core-dev 02:12 -!- promag [~promag@bl23-83-33.dsl.telepac.pt] has joined #bitcoin-core-dev 02:14 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev 02:18 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 252 seconds] 02:22 -!- smarti [~gruqds@fs-93-93-44-38.fullsave.info] has quit [Remote host closed the connection] 02:22 -!- fuqaiq [~gruqds@fs-93-93-44-38.fullsave.info] has joined #bitcoin-core-dev 02:23 -!- fuqaiq [~gruqds@fs-93-93-44-38.fullsave.info] has quit [Remote host closed the connection] 02:29 -!- vexbuy [~vexbuy@212.88.56.119] has joined #bitcoin-core-dev 02:32 -!- vexbuy [~vexbuy@212.88.56.119] has quit [Client Quit] 02:34 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev 02:35 -!- anome [~anome@unaffiliated/anome] has quit [Client Quit] 02:37 < 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. 02:37 < gmaxwell> Should it be a goal for 0.19? 0.20? 02:38 < gmaxwell> Bitcoin core makes it pretty easy to get other addresses when you need them for compatiblity, fortunately. 02:39 < 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. 02:39 < 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. 02:40 < gmaxwell> But maybe announcing a plan to default by version X might help some parties prioritize. 02:46 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev 02:48 -!- anome [~anome@unaffiliated/anome] has quit [Client Quit] 02:49 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev 02:49 -!- anome [~anome@unaffiliated/anome] has quit [Client Quit] 02:49 -!- zhangzf [~zhangzf@106.38.157.147] has quit [Remote host closed the connection] 02:51 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev 02:52 -!- timothy [~tredaelli@redhat/timothy] has quit [Ping timeout: 245 seconds] 02:56 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 255 seconds] 03:00 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 03:11 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 03:12 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 03:19 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 03:23 -!- schmidty [~schmidty@104-7-216-111.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-core-dev 03:23 -!- schmidty [~schmidty@104-7-216-111.lightspeed.austtx.sbcglobal.net] has quit [Changing host] 03:23 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev 03:24 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev 03:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 03:37 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 245 seconds] 03:38 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 03:51 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev 04:23 < instagibbs> a hotter take would be to make segwit v1 unenforced inside p2sh 04:24 < instagibbs> bad idea for money-loss reasons :) 04:26 -!- anome [~anome@unaffiliated/anome] has quit [] 04:28 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev 04:30 < gmaxwell> I dunno if it would be likely to result in money loss. 04:31 < gmaxwell> There is a fine line between encouragement and arm bending though. 04:31 < gmaxwell> if it's taking e.g. ledger >1 year to add support, maybe more encouragement is required. 04:43 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 04:46 < fanquake> fwiw i opened #15560 for discussion 04:46 < gribble> https://github.com/bitcoin/bitcoin/issues/15560 | When to make bech32 the default -addresstype? · Issue #15560 · bitcoin/bitcoin · GitHub 04:46 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds] 04:58 < luke-jr> IMO making segwit v1 unenforced inside p2sh is more of bludgeoning than arm bending :P 04:59 < luke-jr> (policy rejection might be more like arm bending) 05:03 -!- jonatack [58aba822@gateway/web/freenode/ip.88.171.168.34] has joined #bitcoin-core-dev 05:06 -!- promag_ [~promag@195.54.168.134] has quit [Remote host closed the connection] 05:13 -!- hex17or [~hex17or@HSI-KBW-091-089-197-016.hsi2.kabel-badenwuerttemberg.de] has quit [Quit: leaving] 05:18 -!- Skirmant [~Skirmant@78-62-14-181.static.zebra.lt] has quit [Ping timeout: 245 seconds] 05:20 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has joined #bitcoin-core-dev 05:35 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/] 05:38 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has joined #bitcoin-core-dev 05:43 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has quit [Ping timeout: 246 seconds] 05:52 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer] 05:53 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev 05:55 -!- Aaronvan_ is now known as AaronvanW 06:13 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 06:13 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d211edb34982...923d87497c7c 06:13 < bitcoin-git> bitcoin/master fa58a2e MarcoFalke: contrib: Bump gitian descriptors for 0.19 06:13 < bitcoin-git> bitcoin/master 923d874 MarcoFalke: Merge #15528: contrib: Bump gitian descriptors for 0.19 06:13 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 06:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 06:14 < 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 06:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 06:20 -!- Skirmant [~Skirmant@78-62-14-181.static.zebra.lt] has joined #bitcoin-core-dev 06:26 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 06:26 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/923d87497c7c...efed9809b4fa 06:26 < bitcoin-git> bitcoin/master 82c3b3f practicalswift: Remove sharp edge (uninitialized m_filter_type) when using the compiler-ge... 06:26 < bitcoin-git> bitcoin/master efed980 Wladimir J. van der Laan: Merge #15532: Remove sharp edge (uninit member) when using the compiler-ge... 06:26 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 06:27 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 06:27 < 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 06:27 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 06:35 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev 06:43 -!- promag [~promag@bl23-83-33.dsl.telepac.pt] has quit [Remote host closed the connection] 06:44 -!- promag [~promag@bl23-83-33.dsl.telepac.pt] has joined #bitcoin-core-dev 06:49 -!- promag_ [~promag@bl23-83-33.dsl.telepac.pt] has joined #bitcoin-core-dev 06:49 -!- promag [~promag@bl23-83-33.dsl.telepac.pt] has quit [Read error: Connection reset by peer] 07:17 -!- hex17or [~hex17or@HSI-KBW-091-089-197-016.hsi2.kabel-badenwuerttemberg.de] has joined #bitcoin-core-dev 07:18 -!- hex17or [~hex17or@HSI-KBW-091-089-197-016.hsi2.kabel-badenwuerttemberg.de] has quit [Client Quit] 07:19 -!- hex17or [~hex17or@HSI-KBW-091-089-197-016.hsi2.kabel-badenwuerttemberg.de] has joined #bitcoin-core-dev 07:21 -!- jonatack [58aba822@gateway/web/freenode/ip.88.171.168.34] has quit [] 07:23 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev 07:24 -!- zhangzf [~zhangzf@223.72.58.232] has joined #bitcoin-core-dev 07:31 -!- anome [~anome@unaffiliated/anome] has quit [] 07:38 -!- cubancorona [cubancoron@gateway/vpn/privateinternetaccess/cubancorona] has quit [Remote host closed the connection] 07:38 -!- cubancorona [cubancoron@gateway/vpn/privateinternetaccess/cubancorona] has joined #bitcoin-core-dev 07:39 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection] 07:43 -!- asdfgarev [536117fb@gateway/web/freenode/ip.83.97.23.251] has joined #bitcoin-core-dev 07:43 -!- asdfgarev [536117fb@gateway/web/freenode/ip.83.97.23.251] has quit [Client Quit] 08:05 -!- jarthur [~jarthur@207.114.244.5] has joined #bitcoin-core-dev 08:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 08:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 08:09 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-immaryhfbnctletn] has joined #bitcoin-core-dev 08:21 -!- Soligor [~Soligor@unaffiliated/soligor] has joined #bitcoin-core-dev 08:34 -!- zhangzf [~zhangzf@223.72.58.232] has quit [Remote host closed the connection] 08:36 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Read error: No route to host] 08:36 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev 08:48 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer] 08:48 -!- promag_ [~promag@bl23-83-33.dsl.telepac.pt] has quit [Remote host closed the connection] 08:48 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev 08:49 -!- promag [~promag@bl23-83-33.dsl.telepac.pt] has joined #bitcoin-core-dev 09:03 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 09:07 -!- Bullit [~Bullit01@042-236-158-163.dynamic.caiway.nl] has quit [Quit: Leaving] 09:07 -!- jungly [~quassel@79.8.200.97] has quit [Remote host closed the connection] 09:12 -!- Bullit [~Bullit01@042-236-158-163.dynamic.caiway.nl] has joined #bitcoin-core-dev 09:13 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 09:28 -!- ap4lmtree [ap4lmtree@unaffiliated/ap4lmtree] has quit [Remote host closed the connection] 09:28 -!- ap4lmtree [ap4lmtree@unaffiliated/ap4lmtree] has joined #bitcoin-core-dev 09:48 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer] 09:48 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev 09:49 -!- qrestlove [~qrestlove@2601:446:c201:f560:2115:d724:c123:1a9] has joined #bitcoin-core-dev 09:50 -!- promag_ [~promag@83.223.248.22] has joined #bitcoin-core-dev 09:56 -!- Deinogalerix21 [~Deinogale@81.92.202.18] has joined #bitcoin-core-dev 10:02 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev 10:06 -!- Deinogalerix21 [~Deinogale@81.92.202.18] has quit [Quit: WeeChat 2.4] 10:17 -!- promag_ [~promag@83.223.248.22] has quit [Remote host closed the connection] 10:30 -!- IGHOR [~quassel@93.178.216.72] has quit [Read error: Connection reset by peer] 10:31 -!- IGHOR [~quassel@93.178.216.72] has joined #bitcoin-core-dev 10:33 -!- anome [~anome@unaffiliated/anome] has quit [] 10:39 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev 10:42 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Ping timeout: 268 seconds] 10:43 -!- anome [~anome@unaffiliated/anome] has quit [Client Quit] 10:43 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!] 10:48 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 245 seconds] 10:48 < 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 10:50 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 10:54 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev 10:58 -!- jonatack_ [58aba822@gateway/web/freenode/ip.88.171.168.34] has joined #bitcoin-core-dev 10:59 < sdaftuar> at what point do you think we can nuke getblocks support, and reasonably assume that peers should be using getheaders instead? 11:02 < gmaxwell> Uh, instrument a node and see if anyone is using it now? 11:02 < gmaxwell> (I'm not saying now, but even knowing when would require knowing what use is now) 11:03 < gmaxwell> I hadn't been thinking we would depricate responding to it, but if its not being used anymore then maybe. 11:03 < sdaftuar> i found a bcoin:1.0.2 peer that seems to be using it :( somehow that peer also supports compact blocks(?!) 11:04 < 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. 11:04 < 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. 11:05 < gmaxwell> also careful with believing subver, there is a bunch of stuff that lies. (though in this case I'd believe it) 11:05 -!- anome [~anome@unaffiliated/anome] has quit [] 11:06 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev 11:08 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz] 11:10 -!- anome [~anome@unaffiliated/anome] has quit [Client Quit] 11:13 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev 11:14 -!- rex4539 [~rex4539@ppp-2-84-160-62.home.otenet.gr] has quit [Quit: rex4539] 11:16 -!- rex4539 [~rex4539@ppp-2-84-160-62.home.otenet.gr] has joined #bitcoin-core-dev 11:16 -!- rex4539 [~rex4539@ppp-2-84-160-62.home.otenet.gr] has quit [Client Quit] 11:17 -!- anome [~anome@unaffiliated/anome] has quit [Client Quit] 11:18 -!- rex4539 [~rex4539@ppp-2-84-160-62.home.otenet.gr] has joined #bitcoin-core-dev 11:24 -!- millerti [~millerti@cpe-66-24-91-119.stny.res.rr.com] has joined #bitcoin-core-dev 11:24 -!- promag_ [~promag@83.223.248.22] has joined #bitcoin-core-dev 11:28 -!- promag_ [~promag@83.223.248.22] has quit [Ping timeout: 250 seconds] 11:35 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 11:36 < pinheadmz> gmaxwell: I'm a dev on bcoin team, i can tell you bcash is being not supported. bcoin is our main focus 11:42 < 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 11:42 < 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 11:43 < 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 11:43 < sdaftuar> i also notice plenty of other normal-looking traffic from that peer (inv, cmpctblocks, headers, etc) 11:44 < pinheadmz> when I test against Bitcoin Core, I noticed Core sent getheaders first, then getdata for the actual blocks 11:45 < sdaftuar> yes, that makes sense to me 11:45 < pinheadmz> bcoin does support compact blocks, why is that a (?!) :-) 11:46 < 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 11:46 < sdaftuar> so i would have assumed anyone implemented compact blocks would have swithced to getheaders 11:47 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev 11:47 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer] 11:48 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev 11:48 -!- jcorgan [~jcorgan@64-142-68-61.dsl.static.sonic.net] has joined #bitcoin-core-dev 11:48 -!- shesek [~shesek@5.22.134.245] has joined #bitcoin-core-dev 11:48 -!- shesek [~shesek@5.22.134.245] has quit [Changing host] 11:48 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev 11:48 < sdaftuar> pinheadmz: any idea why bcoin still uses getblocks? sounds like you are saying that sometimes it uses getheaders instead? 11:49 -!- anome [~anome@unaffiliated/anome] has quit [Client Quit] 11:51 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev 11:51 < 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. 11:51 -!- jcorgan_ [~jcorgan@64-142-68-61.dsl.static.sonic.net] has quit [Ping timeout: 246 seconds] 11:51 < pinheadmz> Actually Im curious why Core sends `getheaders` first, an then requests the full blocks? 11:51 < sipa> pinheadmz: how would it know what blocks to fetch? 11:52 < 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. 11:52 < sipa> you can find out the block hashes using getblocks or getheaders, but the latter lets you verify PoW before fetching the actual blocks 11:52 < pinheadmz> from `inv` 11:52 < pinheadmz> makes sense 11:52 < sipa> pinheadmz: that's only for newly mined blocks 11:52 < sipa> (or in response to getblocks...) 11:53 < sipa> and with BIP130, new blocks are also announced using headers instead of invs 11:53 < sipa> but that's optionally negotiated between peers 11:53 < gmaxwell> sdaftuar: I considered it deprecated too, fwiw, (though didn't expect it to get disabled anytime soon-- it's just useless/redundant now) 11:54 < gmaxwell> pinheadmz: a header is not much larger than an INV but radically more useful. 11:54 < gmaxwell> pinheadmz: so essentially for blocks we'd replaced INVs with headers. 11:54 < 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 11:55 < pinheadmz> gmaxwell: ok thanks I see this now. SO `getheaders` asks the peer to just send headers without an `inv` 11:55 < pinheadmz> same behavior with SPV wallets 11:55 < sipa> pinheadmz: it sends headers instead of inv 11:55 < gmaxwell> pinheadmz: yes, its pretty much exactly like getblocks but sends headers. 11:55 -!- ap4lmtree [ap4lmtree@unaffiliated/ap4lmtree] has quit [Read error: Connection reset by peer] 11:55 < pinheadmz> then headers are verified, then `getdata` with block hashses 11:55 < sdaftuar> right 11:55 < sipa> right 11:56 < gmaxwell> right 11:56 < sipa> bitcoin core since 0.10 uses this as synchronization mechanism; it's called headers-first sync 11:56 < tryphe> how were blocks gotten before getheaders again? just block #? the new way has much better performance 11:57 < 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. 11:57 < sipa> tryphe: getblocks -> inv -> getdata -> block 11:57 < sipa> getblocks takes a locator and a count, and responds with an inv announcing the next count block hashesd 11:58 -!- anome [~anome@unaffiliated/anome] has quit [] 11:58 < sipa> iirc 11:58 < sipa> the protocol doesn't expose anything by height 11:58 < sipa> as height is ambiguous in the presence of brances 11:59 < 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 :) 11:59 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 240 seconds] 12:01 < pinheadmz> thanks guys, going to get the team on BIP130 12:01 < sipa> bip130 is a step being headers-first sync 12:01 < sipa> *beyond 12:02 < pinheadmz> is there a spec for headers first sync? (besides, this chat :-) which i think is pretty clear) 12:02 < gmaxwell> sdaftuar: yea, when you said you wanted to remove it that was what I assumed you wanted to remove. 12:02 < sdaftuar> (in particular it sounds like bcoin already implements bip 152, which is a step beyond bip 130.) 12:02 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has left #bitcoin-core-dev [] 12:02 < sipa> kthxbye 12:03 -!- Bullit [~Bullit01@042-236-158-163.dynamic.caiway.nl] has quit [Read error: Connection reset by peer] 12:03 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 12:03 < sipa> pinheadmz: no, not a spec - it's just a way of doing things, not really a protocol 12:03 < sipa> (it didn't need any changes to the p2p protocol) 12:04 < pinheadmz> will `getblocks` ever be unsupported? 12:04 < sipa> as getheaders/headers existed for years before we started using it for block syncing 12:04 < gmaxwell> pinheadmz: that was the subject of discussion. 12:04 < sdaftuar> pinheadmz: i hope so, but i dunno. i might send an email to the -dev list asking if anyone would object? 12:04 < sipa> sdaftuar: seems premature at this point 12:04 < sdaftuar> sipa: yeah 12:05 < gmaxwell> sdaftuar: maybe wait a bit so we don't waste time with 'bcoin' objecting, at least. 12:05 < 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 12:05 < gmaxwell> unfortunate to have to keep around the feeding hack. 12:05 < gmaxwell> sdaftuar: yes, thats fair, and something we should do. 12:06 < sdaftuar> pinheadmz: thanks for jumping on here to discuss 12:06 < pinheadmz> thanks for bringing it up! 12:06 -!- Squidicuz [~squid@pool-72-74-34-120.bstnma.fios.verizon.net] has quit [Quit: Oh no, not again] 12:11 < 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). 12:44 -!- mmgen [~mmgen@gateway/tor-sasl/mmgen] has quit [Quit: (https://github.com/mmgen) leaving] 12:51 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev 12:56 -!- booyah [~bb@193.25.1.157] has quit [Read error: Connection reset by peer] 12:56 -!- nullptr| [~nullptr|@ip-94-112-134-45.net.upcbroadband.cz] has quit [Ping timeout: 268 seconds] 12:57 -!- booyah [~bb@193.25.1.157] has joined #bitcoin-core-dev 13:01 -!- nullptr| [~nullptr|@ip-94-112-134-45.net.upcbroadband.cz] has joined #bitcoin-core-dev 13:04 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz] 13:04 < sipa> gmaxwell: i'm gathering statistics on the prevalance of lowr transactions... and the numbers are surprisingly inconsistent when broken down by #sigs/tx 13:04 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 13:05 < sipa> for 1 sig/tx: 3.4% above 1/2 13:05 < sipa> for 2 sig/tx: 4.9% above 1/4 13:05 < sipa> for 3 sig/tx: 8.6% above 1/8 13:05 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 13:06 < sipa> for 4 sig/tx: 7.2% above 1/16 13:06 < sipa> for 5 sig/tx: 11.6% abive 1/32 13:06 < sipa> for 6 sig/tx: 5% above 1/64 13:06 < sipa> for 7 sig/tx: 10.9% above 1/128 13:08 < gmaxwell> why are you changing the threshold and number of sigs? 13:09 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 245 seconds] 13:10 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 13:13 -!- ap4lmtree [ap4lmtree@unaffiliated/ap4lmtree] has joined #bitcoin-core-dev 13:13 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 13:13 -!- promag [~promag@bl23-83-33.dsl.telepac.pt] has quit [Remote host closed the connection] 13:14 -!- promag [~promag@bl23-83-33.dsl.telepac.pt] has joined #bitcoin-core-dev 13:14 < sipa> gmaxwell: because in tx with 5 sigs, there is a 1/32 chance that non-lowr wallets will produce a lowr solution anyway 13:15 < gmaxwell> oh I thought that was the definition of lowness. :) 13:16 < sipa> gmaxwell: oh, i see my statement may be misinterpreted 13:17 < sipa> i mean for 5 sig/tx, (11.6% + 1/32) of transactions are fully lowr 13:17 < 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. 13:25 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 13:26 < echeveria> sipa: I'd expect that really. 13:27 < 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. 13:29 < 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. 13:29 < echeveria> there's a very small number of 1 of 1 P2SH transactions too. 13:29 < gmaxwell> the coinjoin bounty fund is a mixed compressed multisig. 13:31 < 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. 13:32 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 13:33 -!- promag [~promag@bl23-83-33.dsl.telepac.pt] has quit [Remote host closed the connection] 13:33 -!- promag [~promag@bl23-83-33.dsl.telepac.pt] has joined #bitcoin-core-dev 13:35 -!- jarthur [~jarthur@207.114.244.5] has quit [] 13:35 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 245 seconds] 13:43 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer] 13:44 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev 13:51 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 252 seconds] 13:55 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 14:02 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev 14:03 -!- promag_ [~promag@bl23-83-33.dsl.telepac.pt] has joined #bitcoin-core-dev 14:04 -!- promag_ [~promag@bl23-83-33.dsl.telepac.pt] has quit [Remote host closed the connection] 14:05 -!- Squidicuz [~squid@pool-72-74-34-120.bstnma.fios.verizon.net] has joined #bitcoin-core-dev 14:06 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 14:23 -!- pso47 [acfb39a5@gateway/web/freenode/ip.172.251.57.165] has joined #bitcoin-core-dev 14:25 -!- promag_ [~promag@bl23-83-33.dsl.telepac.pt] has joined #bitcoin-core-dev 14:30 -!- promag_ [~promag@bl23-83-33.dsl.telepac.pt] has quit [Ping timeout: 245 seconds] 14:52 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 14:52 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 268 seconds] 14:59 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 15:05 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 250 seconds] 15:08 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 15:18 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 15:23 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-immaryhfbnctletn] has quit [Quit: Connection closed for inactivity] 15:26 -!- promag_ [~promag@bl23-83-33.dsl.telepac.pt] has joined #bitcoin-core-dev 15:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 15:45 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds] 15:57 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 15:58 -!- pso47 [acfb39a5@gateway/web/freenode/ip.172.251.57.165] has quit [Ping timeout: 256 seconds] 16:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds] 16:05 -!- shesek [~shesek@5.22.134.245] has joined #bitcoin-core-dev 16:05 -!- shesek [~shesek@5.22.134.245] has quit [Changing host] 16:05 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev 16:08 -!- d_t [~d_t@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev 16:26 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 268 seconds] 16:28 < sipa> gmaxwell: my formula is wrong 16:29 < sipa> if a fraction p of n-sig transactions is made using lowr, then you would observe a fraction x = p + (1-p)*0.5^n of lowr transactions 16:29 < sipa> so given x, p can be computed as (x*2^n - 1)/(2^n - 1) 16:38 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer] 16:38 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev 16:39 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 16:41 < sipa> 2019-03-09T00:39:53.454594Z Stats LOWR 1: 1478633 0.06805 16:41 < sipa> 2019-03-09T00:39:53.454601Z Stats LOWR 2: 444741 0.0659343 16:41 < sipa> 2019-03-09T00:39:53.454611Z Stats LOWR 3: 70850 0.0976832 16:41 < sipa> 2019-03-09T00:39:53.454618Z Stats LOWR 4: 53930 0.07754 16:41 < sipa> 2019-03-09T00:39:53.454625Z Stats LOWR 5: 17363 0.121424 16:41 < sipa> for the last 1000 blocks 16:42 < sipa> the last number is the estimated ratio of lowr-software-produced transactions 16:54 < gmaxwell> sipa: did you not bother with stats for more than 5 signatures? 16:57 < sipa> i have numbers up to 256 sigs 16:58 < sipa> here are the first 50: https://zerobin.net/?26e00991169c6c76#QYnu/CQ+ywAhOUqaLqzx+HbQMGQFxvI8zgMyuBkUcSw= 17:06 -!- dviola [~diego@unaffiliated/dviola] has quit [Quit: WeeChat 2.4] 17:10 < gmaxwell> so 6.87382% of transactions overall. 17:10 < sipa> is that the weighted average? 17:12 < gmaxwell> I took your counts time percentage and added it up. 17:13 < sipa> yeah 17:47 -!- promag_ [~promag@bl23-83-33.dsl.telepac.pt] has quit [Remote host closed the connection] 17:49 < sipa> gmaxwell: https://zerobin.net/?43912925929e086e#2I4qQY2fS6KwIO8OOynLImNi48ZCm3UgluqTeRI3FtA= 17:49 < gribble> https://github.com/bitcoin/bitcoin/issues/2 | Long-term, safe, store-of-value · Issue #2 · bitcoin/bitcoin · GitHub 17:49 < sipa> last 10000 blocks 17:49 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 17:55 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 18:02 -!- promag_ [~promag@bl23-83-33.dsl.telepac.pt] has joined #bitcoin-core-dev 18:04 < sipa> 5.3856% 18:05 -!- d_t [~d_t@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 252 seconds] 18:17 -!- millerti [~millerti@cpe-66-24-91-119.stny.res.rr.com] has quit [Ping timeout: 250 seconds] 18:35 -!- promag_ [~promag@bl23-83-33.dsl.telepac.pt] has quit [Remote host closed the connection] 18:36 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer] 18:37 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev 18:48 -!- promag_ [~promag@bl23-83-33.dsl.telepac.pt] has joined #bitcoin-core-dev 18:53 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 18:54 -!- promag_ [~promag@bl23-83-33.dsl.telepac.pt] has quit [Remote host closed the connection] 19:04 -!- d_t [~d_t@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev 19:10 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has joined #bitcoin-core-dev 19:27 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Ping timeout: 255 seconds] 19:36 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer] 19:37 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev 19:38 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 19:51 -!- d_t [~d_t@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has quit [Read error: No route to host] 19:51 -!- d_t [~d_t@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev 19:51 -!- promag_ [~promag@bl23-83-33.dsl.telepac.pt] has joined #bitcoin-core-dev 19:55 -!- promag_ [~promag@bl23-83-33.dsl.telepac.pt] has quit [Ping timeout: 245 seconds] 20:02 -!- qrestlove [~qrestlove@2601:446:c201:f560:2115:d724:c123:1a9] has quit [Ping timeout: 252 seconds] 20:30 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has quit [Remote host closed the connection] 20:36 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer] 20:37 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev 20:49 -!- zhangzf [~zhangzf@223.72.44.127] has joined #bitcoin-core-dev 20:58 -!- zhangzf [~zhangzf@223.72.44.127] has quit [Remote host closed the connection] 21:01 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has quit [Quit: Lost terminal] 21:02 -!- zhangzf [~zhangzf@223.72.58.232] has joined #bitcoin-core-dev 21:26 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection] 21:36 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer] 21:37 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev 21:39 -!- zhangzf [~zhangzf@223.72.58.232] has quit [Remote host closed the connection] 21:45 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 21:45 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/efed9809b4fa...12408d33c6ac 21:45 < bitcoin-git> bitcoin/master 32da92b Wladimir J. van der Laan: gitian: Improve error handling 21:45 < bitcoin-git> bitcoin/master 12408d3 Wladimir J. van der Laan: Merge #15549: gitian: Improve error handling 21:45 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 21:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 21:46 < bitcoin-git> [bitcoin] laanwj pushed 1 commit to 0.18: https://github.com/bitcoin/bitcoin/compare/0fd3632868e2...f810f14cf61d 21:46 < bitcoin-git> bitcoin/0.18 f810f14 Wladimir J. van der Laan: gitian: Improve error handling 21:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 21:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 21:46 < bitcoin-git> [bitcoin] laanwj merged pull request #15549: gitian: Improve error handling (master...2019_03_gitian_error_handling) https://github.com/bitcoin/bitcoin/pull/15549 21:47 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 21:55 -!- promag_ [~promag@bl23-83-33.dsl.telepac.pt] has joined #bitcoin-core-dev 22:00 -!- promag_ [~promag@bl23-83-33.dsl.telepac.pt] has quit [Ping timeout: 255 seconds] 22:02 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 22:02 < bitcoin-git> [bitcoin] fanquake opened pull request #15562: doc: remove duplicate clone step in build-windows.md (master...improved-15550) https://github.com/bitcoin/bitcoin/pull/15562 22:02 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 22:03 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 22:03 < bitcoin-git> [bitcoin] fanquake closed pull request #15550: doc: correct path in build-windows.md (master...patch-1) https://github.com/bitcoin/bitcoin/pull/15550 22:03 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 22:05 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has joined #bitcoin-core-dev 22:06 -!- zhangzf [~zhangzf@223.72.61.161] has joined #bitcoin-core-dev 22:12 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 22:12 < bitcoin-git> [bitcoin] laanwj pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/12408d33c6ac...ff3814880861 22:12 < bitcoin-git> bitcoin/master 4d83401 Suhas Daftuar: [addrman] Improve tried table collision logging 22:12 < bitcoin-git> bitcoin/master 4991e3c Suhas Daftuar: [net] feeler connections can be made to outbound peers in same netgroup 22:12 < bitcoin-git> bitcoin/master f71fdda Suhas Daftuar: [addrman] Ensure collisions eventually get resolved 22:12 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 22:13 -!- zhangzf [~zhangzf@223.72.61.161] has quit [Remote host closed the connection] 22:13 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 22:13 < bitcoin-git> [bitcoin] laanwj merged pull request #15486: [addrman, net] Ensure tried collisions resolve, and allow feeler connections to existing outbound netgroups (master...2019-02-addrman-collisions) https://github.com/bitcoin/bitcoin/pull/15486 22:13 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 22:19 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev 22:36 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer] 22:37 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev 22:43 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev 22:53 -!- rex4539 [~rex4539@ppp-2-84-160-62.home.otenet.gr] has quit [Quit: rex4539] 23:07 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 23:07 < bitcoin-git> [bitcoin] fanquake opened pull request #15563: backport: Ensure tried collisions resolve, and allow feeler connections to existing outbound netgroups (0.18...backport-15486-addrman-collisions) https://github.com/bitcoin/bitcoin/pull/15563 23:07 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 23:09 < fanquake> wumpus 15562 is a trivial doc merge 23:10 < fanquake> no idea why the bottom "build using" is italicized, but it doesn't appear that way in the doc 23:10 < wumpus> fanquake: OK 23:10 < wumpus> looks good to me 23:13 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 23:13 < bitcoin-git> [bitcoin] laanwj pushed 5 commits to 0.18: https://github.com/bitcoin/bitcoin/compare/f810f14cf61d...936ef73fabc9 23:13 < bitcoin-git> bitcoin/0.18 561b00a Suhas Daftuar: [addrman] Improve tried table collision logging 23:13 < bitcoin-git> bitcoin/0.18 487f0c3 Suhas Daftuar: [net] feeler connections can be made to outbound peers in same netgroup 23:13 < bitcoin-git> bitcoin/0.18 333be7a Suhas Daftuar: [addrman] Ensure collisions eventually get resolved 23:13 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 23:13 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 23:13 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/ff3814880861...6b2ee268be45 23:13 < bitcoin-git> bitcoin/master 5bd0788 Ferdinando M. Ametrano: doc: correct path in build-windows.md 23:13 < bitcoin-git> bitcoin/master 6b2ee26 Wladimir J. van der Laan: Merge #15562: doc: remove duplicate clone step in build-windows.md 23:13 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 23:14 < fanquake> I shall close my backport of 15486 then heh 23:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 23:14 < bitcoin-git> [bitcoin] laanwj merged pull request #15562: doc: remove duplicate clone step in build-windows.md (master...improved-15550) https://github.com/bitcoin/bitcoin/pull/15562 23:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 23:15 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev 23:15 < wumpus> fanquake: oh sorry hadn't seen it 23:15 < fanquake> np 23:16 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 23:16 < bitcoin-git> [bitcoin] fanquake closed pull request #15563: backport: Ensure tried collisions resolve, and allow feeler connections to existing outbound netgroups (0.18...backport-15486-addrman-collisions) https://github.com/bitcoin/bitcoin/pull/15563 23:16 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 23:17 < wumpus> fanquake: it was a clean cherry-pick right? 23:17 < fanquake> yes 23:17 < wumpus> phew 23:19 -!- Krusty [~Mutter@88.202.183.117] has joined #bitcoin-core-dev 23:21 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection] 23:25 < wumpus> I really want to improve -getinfo now that it's no longer server side, e.g. show regtest/testnet/mainnet, make some information per wallet 23:25 < wumpus> so if anyone has ideas let me know 23:26 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev 23:27 < gmaxwell> wumpus: pilfer ideas from that ncurses interface someone did a while back? 23:30 < wumpus> maybe! to be clear I intend to keep it in JSON format, just want to update for changes since 0.10 or so when it last was depreceated and diceded to never change it again 23:32 < gmaxwell> well one thing in terms of cli usability maybe don't do what many of our other info rpcs have done and put a billion and one vaguely useful things so that when you run them the good stuff scrolls off the top and its hard to sort out anything useful. :P 23:32 < wumpus> removing stuff is open for suggestion too 23:32 < wumpus> I mean, 'improve' doesn't always mean 'creep any possible feature into it' 23:33 < gmaxwell> exactly. 23:33 < gmaxwell> or alternatively, go fetch some useful fields out of e.g. getblockchaininfo 23:34 < gmaxwell> I'll comment the next time I get wall of texted when trying to get a frequently used field. 23:35 < wumpus> I'd say a good requirement for information on it is that it's dynamic, it's meant as a command for checking the status after all 23:36 < wumpus> things that are only dependent on on-time configuration might be better to leave off 23:36 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer] 23:37 < wumpus> (I mean, how useful is 'protocolversion' on there for example?) or 'keypoololdest', or settings like 'paytxfee' 23:37 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev 23:39 < wumpus> but, say, the hash of the most recent block would be useful to have 23:39 < fanquake> could change testnet: to something like network, then specify main/test/reg ? 23:39 < wumpus> fanquake: yes exactly 23:40 < wumpus> that would be a simple and non-controversial improvement 23:41 < wumpus> just grab getblockchaininfo.main directly 23:41 < wumpus> eh, .chain 23:42 < wumpus> "verificationprogress" is also more or less useful, though only during initial sync 23:44 < gmaxwell> yea, I think what I mostly use getblockchaininfo is the hash of the most recent block, and its scrolled off... 23:44 -!- Krusty_ [~Mutter@195.181.165.4] has joined #bitcoin-core-dev 23:45 < gmaxwell> do we have anything that returns the time of the last updatetip? 23:45 < fanquake> Maybe we could do something better for multiwallet use? i.e at the moment walletversion and balance are both just "null" if >1 wallet loaded 23:45 < fanquake> * same for keypool* 23:45 < wumpus> fanquake: walletversion doesn't need to be in there at all, but yeah, it should *list* wallets 23:45 < gmaxwell> keypool shoudl probably be dropped. 23:45 < wumpus> gmaxwell: I don't think so 23:46 < wumpus> fanquake: the only interesting thing about the wallet in getinfo is the balance, so it could be a object {'walletname': balance} or such then it doesn't really become longer as well 23:47 < wumpus> gmaxwell: do we even keep track of the time of an updatetip? 23:48 < sipa> wumpus: IsInitialBlockDownload does iirc 23:48 -!- Krusty [~Mutter@88.202.183.117] has quit [Ping timeout: 255 seconds] 23:48 -!- Krusty_ [~Mutter@195.181.165.4] has quit [Client Quit] 23:49 < wumpus> sipa: ok-in that case it'd make sense to report that on getblockchaininfo, I guess! 23:57 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 23:57 < bitcoin-git> [bitcoin] fanquake opened pull request #15564: cli: remove duplicate wallet fields from -getinfo (master...cli-remove-duplicate-entries) https://github.com/bitcoin/bitcoin/pull/15564 23:57 -!- d_t [~d_t@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 245 seconds] 23:58 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] --- Log closed Sat Mar 09 00:00:11 2019