< gmaxwell>
phantomcircuit: the sender of a compact block can include additional transactions with their message, per their own decision, in the hopes that it'll help you reconstruct the block.
< luckydogchina>
Hi, guys. I'm a new developer.
< luckydogchina>
Has the lightning network been released?
< luckydogchina>
What features are mainly developed now in bitcoin-core?
< sipa>
kallewoof: sorry for hammering on the coin selection policy change in your PR, but I'm very concerned about this having unintended effects on fees and/or UTXO set growth
< kallewoof>
sipa: Understood. I think it will have limited consequences, though. It only affects someone who has address reuse and they may end up with a minor increase in fees in return for increased privacy. They also need to enable the avoid reuse flag themselves.
< sipa>
kallewoof: not that i suspect that anything is wrong with it, but it's just very hard to reason about the long term effects of such policy changes, so I'd really only want to make them after extensive simulations (the sort of simulations achow101 is doing for #13307)
< kallewoof>
sipa: I'll think of alternatives to that change, but I think it will be difficult. The existing algorithms sort of only pick the lowest larger as a last effort, so they will de-prioritize the privacy increase given by the change..
< kallewoof>
BnB/knapsack I mean
< sipa>
kallewoof: i understand, but i expect you can up woth a dozen scenarios why the specific algorithms we're using now may be suboptimal for various goals
< sipa>
*come up
< sipa>
kallewoof: once we get rid of the knapsack fallback strategy i expect this will be less of a concern too
< sipa>
there is mr. coin selection
< kallewoof>
sipa: Problem is, this algorithm actually makes things worse without that change. :/ We go from 'perhaps be lucky and pick two A utxo's' to 'purposefully avoid the two A utxo's because they sum to > than target'...
< kallewoof>
Maybe I should focus on simulations and abandon hopes of a 0.17 merge.
< sipa>
kallewoof: i had also hoped this could go in as just a simple change with limited impact that clearly can't hurt
< sipa>
kallewoof: but if you need to make policy changes that seem unrelated, it looks like a potentially far more invasive thing
< sipa>
i hope others chime in about this :)
< sipa>
kallewoof: i'm not sure i agree it reduces privacy in this scenario even; yes, it may prefer b,c over a,a - but it's never going to pick a,b or a,c
< kallewoof>
sipa: that's true...
< kallewoof>
sipa: it doesn't reduce privacy, but it loses a potential opportunity to increase it
< kallewoof>
sipa: maybe that's acceptable as a first merge, with a policy change afterwards...
< sipa>
kallewoof: i expect in 0.18 the knapsack solver will be gone regardless
< kallewoof>
sipa: Oh. I didn't realize this was in the knapsack solver only. I somehow thought it happened before the algo
< sipa>
i didn't check; but that sort of logic sounds like the kind of hacks i expect in the knapsack solver :)
< kallewoof>
Yeah.. That's because I wrote this code before the BnB merge.
< kallewoof>
I'm gonna remove it from the PR for now with a potential follow-up that adds it if it seems warranted.
< sipa>
sgtm; i'll review more in a couple hours
< bitcoin-git>
[bitcoin] masonicboom opened pull request #13698: doc: Document contributing a scripted diff (master...scripted-diff-docs) https://github.com/bitcoin/bitcoin/pull/13698
< AHemlocksLie>
I'm interested in getting involved and making some contributions, but I've never worked on an open source project like this. What's the best way to jump in? How do I make sure I'm not working on something that's already got 3 other people on it? What can I do to make my work more likely to be accepted so I don't waste time accidentally going against the project?
< kallewoof>
AHemlocksLie: start off reading all the docs you can find on github.com/bitcoin/bitcoin in particular the developer docs and contributor guidelines. Then look at pull requests people have made and get a feel for how the process works. To actually do something, I suggest actually using the software. You run into things you want to improve and then you work on that.
< kallewoof>
If your C++ is weak, you should work on that too, of course.
< AHemlocksLie>
It's rusty, but I used to be decent. Should be able to brush up again. Thanks for the info.
< gmaxwell>
kallewoof: if it's any consolation, it's better for a transaction to spend b,c than it is for two different transactions to spend a and a,b the 'merging' of coin paths is a lot less harmful to privacy than the splitting of it.
< kallewoof>
gmaxwell: Yeah, I guess that's an improvement too.
< provoostenator>
sipa: thanks, I didn't realize gists don't do notifications. Maybe Microsoft can fix that :-)
< gribble>
https://github.com/bitcoin/bitcoin/issues/13247 | Add tests to SingleThreadedSchedulerClient() and document the memory model by skeees · Pull Request #13247 · bitcoin/bitcoin · GitHub
< bitcoin-git>
[bitcoin] laanwj closed pull request #13672: Modified in_addr6 cast in CConman class to work with msvc (master...ip6castfix) https://github.com/bitcoin/bitcoin/pull/13672
< wumpus>
for 13672 I was afraid it would bring back some problems, I remember that part of the code being heavily patched and contended already, I hope it's finally ok now
< wumpus>
palimpsest function
< fanquake>
heh. It always seems like the Windows builds/build tools can easily break, and just remain that way for some time
< wumpus>
I don't think many people are building using msvc
< wumpus>
could be because there's not much interest in doing so, or because sipsorcery's guide is not well-known
< fanquake>
yep that's most of the reason I reckon, just not many people building
< wumpus>
at least openbsd and freebsd problems tend to be reported quickly nowadays
< bitcoin-git>
bitcoin/master 41a8c8d MarcoFalke: travis: Check that ~/.bitcoin is never created
< bitcoin-git>
bitcoin/master fabe28a MarcoFalke: qa: Temporarily disable test that reads the default datadir location
< bitcoin-git>
bitcoin/master 9d26b69 Wladimir J. van der Laan: Merge #13687: travis: Check that ~/.bitcoin is never created...
< bitcoin-git>
[bitcoin] laanwj closed pull request #13687: travis: Check that ~/.bitcoin is never created (master...Mf1709-travisHomeDirBtc) https://github.com/bitcoin/bitcoin/pull/13687
< BlueMatt>
gmaxwell: its no doubt long since time to implement prediction, though sadly I dont have time atm :(
< bitcoin-git>
bitcoin/master 417b6c1 Thomas Kerin: bitcoinconsensus: invalid flags should be set to bitcoinconsensus_error type, add test cases covering bitcoinconsensus error codes
< bitcoin-git>
bitcoin/master 585db54 Wladimir J. van der Laan: Merge #13655: bitcoinconsensus: invalid flags error should be set to bitcoinconsensus_err...
< sipa>
promag: i would like it to be, but it is very late
< sipa>
if it's not for 0.17, it'll need to be a separate interfacs rather than replacing the existing ones
< echeveria>
> 2018-07-18 16:39:53.624243 Successfully reconstructed block 00000000000000000000a34548e4384fb22321382fb3d101f1c9281813440a28 with 1 txn prefilled, 0 txn from mempool (incl at least 0 from extra pool) and 2348 txn requested
< echeveria>
hm. sort of feels like blocksonly=1 should unset compact blocks :)
< sipa>
can anyone still access the BIP174 PR without getting a unicorn?
< gmaxwell>
echeveria: hm. I thought I changed it a while back to not use CB if your mempool is empty.
< wumpus>
unicorns here while logged in, but not in private browsing
< wumpus>
?timeline_per_page=20
< wumpus>
works
< sipa>
wumpus: oh!
< gmaxwell>
sipa: another alternative, though I'd like to see it go in too, would be to mark scantoutset expiremental so we can change the interface without surprising anyone.
< bitcoin-git>
bitcoin/master cd3f4aa Andrew Chow: Decouple wallet version from client version...
< bitcoin-git>
bitcoin/master 4a3e8c5 Wladimir J. van der Laan: Merge #13500: [wallet] Decouple wallet version from client version...
< bitcoin-git>
[bitcoin] laanwj closed pull request #13500: [wallet] Decouple wallet version from client version (master...decouple-wallet-version) https://github.com/bitcoin/bitcoin/pull/13500
< wumpus>
gmaxwell,sipa: marking scantxoutset as experimental sounds good to me. People will initially be learning what to do with the method anyhow, there might be some other things that need to be changed based on that learning process
< wumpus>
(independent on whether it gets merged)
< gmaxwell>
I think in general we should be more agressive at marking new RPC features expiremental, more agressive at adding them, and more agressive at removing them or changing them. :)
< bitcoin-git>
[bitcoin] mitchellcash opened pull request #13706: doc: Minor improvements to release-process.md (master...release_process_doc) https://github.com/bitcoin/bitcoin/pull/13706
< gmaxwell>
someone is calling for wumpus to be opensourced.
< sipa>
i believe wumpus is a physically unclonable function
< gmaxwell>
There have been some recent advances in cloning PUFs.