< gmaxwell>
So then I guess the confusion there would be that what he'd really want as the alternative is 'hybrid spv mode' in the ln wallet? not in bitcoin core.
< sipa>
only partially related, i think there is a lot of confusion about what "bip157" means; there is (a) the spec, allowing software to implement the filters in a private protocol like wasabi does (b) support for it in bitcoin core via RPC (what the current PRs do) (c) exposing it in core and other software via P2P for trusting peers to use (d) exposing it in core via P2P for non-trusting peers (e) a
< moneyball>
My understanding is that pierre_rochard is focused on onboarding new Bitcoin users via Lightning (with his Lightning Powered Users), and he would like as many of them as possible to run full nodes, but he wants them to be able to use Bitcoin immediately so wants to support BIP157 style light clients. He's also saying if Core doesn't merge support for BIP157, he'd maintain a version of Core with it merged, and run
< harding>
gmaxwell: pierre_rochard maintains an installer that installs Bitcoin Core, LND, and a LN wallet that's capable of using BIP157/158. I think his desire is to allow people to immediately start using LND and the LN wallet using BIP157 filters served from his node while their Bitcoin Core node syncs. That is, I don't think he's talking about hybrid SPV in Bitcoin Core by hybrid SPV via LND/Neutrino/some other wallet.
< gmaxwell>
(someone in #bitcoin tried asking me my opinion about that debate earlier, and I thought it would be nice to actually understand it before responding...)
< bitcoin-git>
[bitcoin] jnewbery opened pull request #15602: [p2] Enable reject messages by default (0.18...reject_message_by_default) https://github.com/bitcoin/bitcoin/pull/15602
< bitcoin-git>
bitcoin/0.18 a01925c Wladimir J. van der Laan: doc: Pre-rc2 translations update
< bitcoin-git>
[bitcoin] luke-jr opened pull request #15600: lockedpool: When possible, use madvise to avoid including sensitive information in core dumps or forked process memory spaces (master...lockedpool_dontdump) https://github.com/bitcoin/bitcoin/pull/15600
< bitcoin-git>
[bitcoin] pstratem opened pull request #15597: Generate log entry when blocks messages are received unexpectedly. (master...2019-03-12-net-unexpected-block) https://github.com/bitcoin/bitcoin/pull/15597
< bitcoin-git>
bitcoin/master 335931d fanquake: rpc: return a number for estimated_feerate in analyzepsbt
< bitcoin-git>
bitcoin/master 8e1704c Wladimir J. van der Laan: Merge #15559: doc: correct analyzepsbt rpc doc
< bitcoin-git>
[bitcoin] practicalswift closed pull request #15589: tests: Teach lint-whitespace.sh to detect missing newline at end of file (master...lint-newline-at-eof) https://github.com/bitcoin/bitcoin/pull/15589
< bitcoin-git>
[bitcoin] practicalswift opened pull request #15589: lint: Teach lint-whitespace.sh to detect missing newline at end of file (master...lint-newline-at-eof) https://github.com/bitcoin/bitcoin/pull/15589
< newbie2019258_>
One more question please: After I added the rpcauth=... line into the config file (bitcoin.conf) how to need activate/accept, I mean maybe need to reload some service(s) or something like that? (I want to use the PHP wrapper to manage bitcoind over RPC)
< bitcoin-git>
[bitcoin] Sjors closed pull request #15567: Make OutputType consistent with Descriptor and return it (master...2019/03/descriptor-output-type) https://github.com/bitcoin/bitcoin/pull/15567
< bitcoin-git>
[bitcoin] achow101 opened pull request #15588: Log the actual wallet file version and no longer publicly expose the "version" record (master...rm-wallet-nfileversion) https://github.com/bitcoin/bitcoin/pull/15588
< bitcoin-git>
bitcoin/master fa55104 MarcoFalke: build: use full version string in setup.exe
< bitcoin-git>
bitcoin/master e577067 Wladimir J. van der Laan: Merge #15548: build: use full version string in setup.exe
< zhangzf>
luke-jr: Thank you. I see the repo. When I clone the bitcoin repo and install depends lib, I use "./autogen.sh", "./configure", "make", "make install". The bin is install in my machione, it is depends shared lib. I want to compile the bitcoin to run on another ubuntu machine.
< zhangzf>
Hi, I want to package Bitcoin Core on Ubuntu, but I don't know how to package it. For windows and macOS, I know that run "make deploy". On Linux, What can I do for it.
< bitcoin-git>
[bitcoin] fanquake opened pull request #15584: build: disable BIP70 support by default (master...disable-bip70-by-default) https://github.com/bitcoin/bitcoin/pull/15584
2019-03-11
< bitcoin-git>
[bitcoin] promag opened pull request #15583: wallet: Ignore recursive_directory_iterator errors in ListWalletDir (master...2019-03-fix-listwalletdir) https://github.com/bitcoin/bitcoin/pull/15583
< bitcoin-git>
[bitcoin] sipa opened pull request #15582: Fix overflow bug in analyzepsbt fee: CAmount instead of int (master...201903_analyzepsbtoverflow) https://github.com/bitcoin/bitcoin/pull/15582
< bitcoin-git>
[bitcoin] dongcarl opened pull request #15581: depends: Make less assumptions about build env (master...2019-03-true-neutral-depends) https://github.com/bitcoin/bitcoin/pull/15581
< bitcoin-git>
[bitcoin] dongcarl opened pull request #15580: depends: native_protobuf: avoid system zlib (master...2019-03-depends-native_protobuf-no-zlib) https://github.com/bitcoin/bitcoin/pull/15580
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #15566: cli: replace testnet with chain and return network name as per BIP70. (master...cli-testnet-to-network) https://github.com/bitcoin/bitcoin/pull/15566
< bitcoin-git>
[bitcoin] ldm5180 opened pull request #15573: dead code: Remove dead option in HexStr conversion (master...hexstr_dead_code) https://github.com/bitcoin/bitcoin/pull/15573
< bitcoin-git>
[bitcoin] rojarsmith opened pull request #15572: Add auto select custom fee when smart fee not initialized. (master...dev) https://github.com/bitcoin/bitcoin/pull/15572
< bitcoin-git>
[bitcoin] rojarsmith closed pull request #15571: Add auto select custom fee when smart fee not initialized. (master...mydev) https://github.com/bitcoin/bitcoin/pull/15571
< bitcoin-git>
[bitcoin] rojarsmith opened pull request #15571: Add auto select custom fee when smart fee not initialized. (master...mydev) https://github.com/bitcoin/bitcoin/pull/15571
< echeveria>
I guess that's a good heuristic for everything other than bitcoin core.
2019-03-09
< gmaxwell>
the security alias just got yet another report, apparently mac AV software is now also claiming that bitcoin is a virus.
< bitcoin-git>
[bitcoin] Sjors opened pull request #15567: Make OutputType consistent with Descriptor and return it (master...2019/03/descriptor-output-type) https://github.com/bitcoin/bitcoin/pull/15567
< luke-jr>
yes, I have that answer typed up waiting for him in #Bitcoin XD
< teslasystems>
Sorry, but I thought that the question is related to development, will post to #bitcoin
< luke-jr>
teslasystems: that's a question for #bitcoin, not here
< teslasystems>
Can anyone tell, where is the button for creating new wallets in Bitcoin Core? It has disappeared after 0.16.3 release
< bitcoin-git>
bitcoin/master 257f750 Wladimir J. van der Laan: Merge #15565: doc: remove release note fragments
< gmaxwell>
(in spite of my love of integers, I'm also not super fond of satoshi interfaces... values are usually too big, and it's perfectly reasonable for bitcoin software to work in sub-satoshi amounts even though thats the network precision)
< gmaxwell>
unfortuantely all these fee estimation sites sprung up around a time when the min relay fee happened to be 1s/b, I think, which is what caused it to be treated as fundimental instead of the bitcoin per/1000b the bitcoin software used in it's interfaces
< gmaxwell>
(feerates and guistuff and time are the things in bitcoin that use floats)
< bitcoin-git>
[bitcoin] fanquake opened pull request #15566: cli: replace testnet with chain and return network name as per BIP70. (master...cli-testnet-to-network) https://github.com/bitcoin/bitcoin/pull/15566
< 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