< bitcoin-git>
[bitcoin] NicolasDorier closed pull request #9985: [QT] Show more descriptive label for pay to yourself entries (master...watchonlylabel) https://github.com/bitcoin/bitcoin/pull/9985
< bitcoin-git>
[bitcoin] NicolasDorier closed pull request #10007: [QT] Remove SendToSelf, and break down its payouts (master...watchonlylabel2) https://github.com/bitcoin/bitcoin/pull/10007
< wumpus>
did anyone have reports of issues/regressions with 0.14.2?
< bitcoin-git>
bitcoin/master 40796e1 Matt Corallo: Remove references to priority that snuck back in in 870824e9....
< bitcoin-git>
bitcoin/master fa1f106 Wladimir J. van der Laan: Merge #10488: Note that the prioritizetransaction dummy value is deprecated, and has no meaning...
< bitcoin-git>
[bitcoin] laanwj closed pull request #10488: Note that the prioritizetransaction dummy value is deprecated, and has no meaning (master...2017-05-dummy-api) https://github.com/bitcoin/bitcoin/pull/10488
< bitcoin-git>
bitcoin/master f28eb80 Luke Dashjr: Bugfix: wallet: Increment "update counter" only after actually making the applicable db changes to avoid potential races...
< bitcoin-git>
bitcoin/master 9d15d55 Luke Dashjr: Bugfix: wallet: Increment "update counter" when modifying account stuff
< bitcoin-git>
bitcoin/master 23fb9ad Luke Dashjr: wallet: Move nAccountingEntryNumber from static/global to CWallet
< fanquake>
wumpus Limited use so far, but nothing obvious has come up.
< bitcoin-git>
bitcoin/master 7222388 Timothy Redaelli: Avoid printing generic and duplicated "checking for QT" during ./configure...
< bitcoin-git>
bitcoin/master ad1a13e Wladimir J. van der Laan: Merge #10549: Avoid printing generic and duplicated "checking for QT" during ./configure...
< bitcoin-git>
[bitcoin] laanwj closed pull request #10549: Avoid printing generic and duplicated "checking for QT" during ./configure (master...check_qt) https://github.com/bitcoin/bitcoin/pull/10549
< cfields>
instagibbs: seems to rely on a very cooperative p2p network...
< sipa>
cfields: not really
< sipa>
it relies on a good percentage of honest nodes to provide an advantage, but non-cooperating nodes can only cause a slowdown
< cfields>
sipa: what prevents uncooperative nodes from fluffing early? Seems it'd only require a small percentage of those nodes to negate all positive effects?
< sipa>
cfields: nothing
< sipa>
though i think the percentage of uncooperative nodes must be very high to negate all advantages
< cfields>
hmm
< sipa>
oh, wow, IWYU is open source
< sipa>
i used it at google, not knowing it was public :)
< morcos>
^^ I couldn't compile without this, in case anyone else is seeing same thing
< bitcoin-git>
[bitcoin] ryanofsky closed pull request #9306: Make CCoinsViewCache::Cursor() return latest data (master...pr/coins-cursor) https://github.com/bitcoin/bitcoin/pull/9306
< bitcoin-git>
[bitcoin] ryanofsky closed pull request #9137: WIP: Allow wallet key import RPCs to track TxOut amounts on -prune nodes (on top of #9306) (master...import-pruned) https://github.com/bitcoin/bitcoin/pull/9137
< amiller>
cfields: that's exactly the model covered in the analysis figure, basically as the number of cooperating nodes increases, the privacy benefit gets better, but the benefit starts kicking in immediately
< cfields>
amiller: good to know, thanks. I'll read in more detail.