< 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.
< sipa>
bitcoin core since 0.10 uses this as synchronization mechanism; it's called headers-first sync
< 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.
< pinheadmz>
when I test against Bitcoin Core, I noticed Core sent getheaders first, then getdata for the actual blocks
< 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.
< shesek>
maybe easier to think about this as "overall negative or positive effect on bitcoin users' privacy" than in morality terms
< gmaxwell>
bitcoin core can but its a setting.
< gmaxwell>
You might want to look over time, you may see the release when bitcoin core wouldn't violate UIH-2.
< 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
< 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.
< 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.
< 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)
< 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.
< 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.
< 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
< 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.
< gmaxwell>
that hurestic will pretty reliably misidentify change for many bitcoin core users right now. :)
< 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?
< gmaxwell>
fees by, then there is probably a changeless solution, and bitcoin core will find it if there is one.
< gmaxwell>
shesek: bitcoin core manages to produce changeless payments quite often, so long as the wallet has many inputs.
< 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?
< gmaxwell>
shesek: IIRC bitcoin core has always violated it from day one. just not that all that often.
< gmaxwell>
shesek: yes, bitcoin core will spend inputs a bit more when fees are low, though right now that behavior is kinda weak
< gmaxwell>
We probably don't want to randomly query them on each start, because if some are bad for your privacy (e.g. logging networks running bitcoin node) then you'll eventually hit them.
< bitcoin-git>
bitcoin/master 28c86de João Barbosa: gui: Drop unused return values in WalletFrame
< bitcoin-git>
bitcoin/master d211edb Jonas Schnelli: Merge #15464: gui: Drop unused return values in WalletFrame
< gmaxwell>
Probably we wouldn't propose implementing the multi-key version for bitcoin, but we had to feel out the design to figure out if it would be useful or not.
< provoostenator>
I like being able to detect when my ISP starts messing with my Bitcoin P2P traffic :-)
< sipa>
instagibbs: his position is that authentication without encryption is pointless (i agree, it mostly is), and that authentication of bitcoin connections is a slippery slope
< bitcoin-git>
[bitcoin] instagibbs opened pull request #15557: Enhance `bumpfee` to include inputs when targeting a feerate (master...bumpall) https://github.com/bitcoin/bitcoin/pull/15557
< wumpus>
andytoshi: that's a good question, normally the bitcoin-dev mailing list would be the best place to solicit feedback like that, but now that it's not working I don't really know
< bitcoin-git>
[bitcoin] Sjors opened pull request #15545: [doc] explain why CheckBlock() is called before AcceptBlock (master...2019/03/clarify-checkblock) https://github.com/bitcoin/bitcoin/pull/15545
< * wumpus>
doesn't even succeed in making the bitcoin core build deterministic so who am I to complain ...
< wumpus>
same for the divergence between my own previous and current builds, except that affects bitcoin-qt
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #15521: Fixed some times can not remove "$SUFFIX-dirty" on version number cor… (master...master) https://github.com/bitcoin/bitcoin/pull/15521
2019-03-05
< booyah>
mmgen: #bitcoin-bans is about discussing bans
< mmgen>
sipa: well, I'd be happy to take it to #bitcoin, but gmaxwell has banned me there, for promoting "snake oil"
< mmgen>
well if i'm banned on #bitcoin, how can I get unbanned?
<@gwillen>
FWIW I think your tool looks cool, although I am skeptical that your alternative to BIP32 is an improvement but I'd be interested to hear about the motivation behind it (but not in this channel, perhaps #bitcoin-dev would accept such a conversation)
< gmaxwell>
My logs show mmgen first joined #bitcoin on feb 23rd and in that time he his linked his tool 35 times.
<@gwillen>
also, in general #bitcoin has a lot of people who are a danger to themselves in terms of running whatever software is in front of them
< mmgen>
gmaxwell: is this a permanent ban from #bitcoin, greg? Just asking. To be honest, I'm astounded. As a long-time participant here, I wasn't expecting this
< zhangzf>
hello, Who have testnet bitcoin? Can you give me some, I want to test code. My address is mgSRBDvv9h2bRgZHGWLo4xQU9PLvssK6Yi
< bitcoin-git>
[bitcoin] gwillen opened pull request #15534: In lint-format-strings, open files sequentially (fix for OS X failure) (master...feature-fix-lint-osx) https://github.com/bitcoin/bitcoin/pull/15534
< bitcoin-git>
[bitcoin] practicalswift opened 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
< harding>
dongcarl: I just tried and it lets me edit via the web interface but git push for the exact same change gives me: remote: Permission to bitcoin-core/bitcoin-devwiki.wiki.git denied to harding.
< dongcarl>
Anyone know how to push to the wiki? I've got `git@github.com:bitcoin-core/bitcoin-devwiki.wiki.git` as my remote and git tells me permission denied
< bitcoin-git>
[bitcoin] rojarsmith opened pull request #15521: Fixed some times can not remove "$SUFFIX-dirty" on version number cor… (master...master) https://github.com/bitcoin/bitcoin/pull/15521
< bitcoin-git>
bitcoin/0.18 742f7dd Wladimir J. van der Laan: build: Bump version to 0.18.0
< bitcoin-git>
[bitcoin] darosior closed pull request #15511: RPC : More user-friendly services field in getnetworkinfo and getpeerinfo (master...services_for_humans) https://github.com/bitcoin/bitcoin/pull/15511
< gribble>
https://github.com/bitcoin/bitcoin/issues/15486 | [addrman, net] Ensure tried collisions resolve, and allow feeler connections to existing outbound netgroups by sdaftuar · Pull Request #15486 · bitcoin/bitcoin · GitHub
< gribble>
https://github.com/bitcoin/bitcoin/issues/15453 | Starting bitcoin-qt with -nowallet and then opening a wallet does not show the wallet · Issue #15453 · bitcoin/bitcoin · GitHub
< gribble>
https://github.com/bitcoin/bitcoin/issues/15453 | Starting bitcoin-qt with -nowallet and then opening a wallet does not show the wallet · Issue #15453 · bitcoin/bitcoin · GitHub
< wumpus>
good, it worked; [bitcoin-git] is logged in as bitcoin-git