< BlueMatt>
I'd like to nominate https://github.com/bitcoin/bitcoin/pull/9026 (well, a variant of it, because that is gonna end up adapting to some reorgs that are in-progress) for 0.13.2
< petertodd>
morcos: again, this is a scenario where bitcoin as you know it is horribly insecure - anyone with >10 machines could attack your min-diff chain. I had a high enough credit limit as a student to buy more machines than that. :)
< petertodd>
Chris_Stewart_5: yes, removiing is a hard fork, but remember we're talking about a situation where bitcoin as you know it is useless, so tha'ts irrelevant IMO
< petertodd>
jeremyrubin: yes, and at that point your idea of what bitcoin is is so insecure as to be useless
< petertodd>
wumpus: right, I mean, w/o the minimum diff thing, the effect would be no different than ensuring bitcoin core shipped with blockchain data
< petertodd>
note that from the point of view of consensus this is technically speaking no different than making bitcoin core come with a set of blockchain data
< BlueMatt>
Frederic94500: we're in the middle of a meeting, please go to #bitcoin
< Frederic94500>
#bitcoin If segwit doesn't activate, he will be activate to the next 2016 blocks?
< jtimon>
I'm still trying to test the blocksigning stuff, but the "custom chain" code that preceeds it is pretty much ready I think (feel free to test it and give suggestions), see https://github.com/bitcoin/bitcoin/pull/8994
<@wumpus>
or magnet:?xt=urn:btih:dbe48c446b1113890644bbef03e361269f69c49a&dn=bitcoin-core-0.13.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&ws=https%3A%2F%2Fbitcoin.org%2Fbin%2F
< btcdrak>
achow101_: looks like everything has been done barring release notes and upload to bitcoin.org
< andytoshi>
kanzure: no, i have a rust json parsing library for bitcoin purposes, a low-priority TODO is for me to aggressively compare its behaviour to that of univalue
< GitHub174>
[bitcoin] rebroad opened pull request #9030: Don't process blocktxns when we have the block already. (master...BlocktxnExits) https://github.com/bitcoin/bitcoin/pull/9030
< btcdrak>
wumpus: well we have tests that compare the json output of "./bitcoin-tx -json ..." with a json file. trailing white space can get trimmed by IDE/editor settings. Trailing white space has no place in a json file. If it wasnt for that nice "log errors as diff" patch to bitcoin-unit-test.py submitted yesterday I would have lost my mind.
< GitHub7>
[bitcoin] laanwj closed pull request #9022: Update release notes to mention dropping OS X 10.7 support (0.13...0-13-1-osx-notes) https://github.com/bitcoin/bitcoin/pull/9022
< gmaxwell>
here is the max from that data, BitClub -0.00042054 HaoBTC 0.03818631 BitFury 0.05457683 BTC.com 0.07372295 SlushPool 0.09595818 BTCC 0.09886828 ViaBTC 0.11170776 F2Pool 0.12080682 Bitcoin.com 0.12846755 AntPool 0.14341536 Unknown 0.16687057 BW.COM 0.18705609 GBMiners 0.24633568 Telco 0.709605 Eligius 1.03414
< GitHub114>
[bitcoin] sdaftuar opened pull request #9026: Fix handling of invalid compact blocks (master...fix-invalidcb-handling) https://github.com/bitcoin/bitcoin/pull/9026
< wumpus>
btcdrak: upstream to jgarzik/univalue, and we can merge it to bitcoin-core/univalue if that takes too long / is urgent
< GitHub151>
[bitcoin] jnewbery opened pull request #9025: getrawtransaction should take a bool for verbose (master...getrawtransbool) https://github.com/bitcoin/bitcoin/pull/9025
< wumpus>
that's slightly curious, maybe getrawtransaction author expected an 'even more verbose' format at some point and pass '2'? it'd have made sense for `getblock` and https://github.com/bitcoin/bitcoin/pull/8704
< GitHub197>
[bitcoin] fanquake opened pull request #9022: Update release notes to mention dropping OS X 10.7 support (0.13...0-13-1-osx-notes) https://github.com/bitcoin/bitcoin/pull/9022
< GitHub119>
[bitcoin] laanwj opened pull request #9020: rpc: Remove invalid explanation from wallet fee message (master...2016_10_wallet_message) https://github.com/bitcoin/bitcoin/pull/9020
< blur3d>
Hey Core. Just a thank you message for your all your work. Keep doing what you guys are doing. Ignore the outside pressures, and keep bitcoin from becoming centeralised. All of the fear mongering ignores the simple fact that the bitcoin network would be near impossible to replicate from scratch. Any transitional periods may have some discomfort, but compromising the network for short term bandaides is for fools.
< GitHub60>
bitcoin/0.13 a32d7c2 Cory Fields: release: bump required osx version to 10.8. Credit jonasschnelli....
< wumpus>
the ancient wallet message I was talking about still exists, but apparently I closed the issue: https://github.com/bitcoin/bitcoin/issues/211 "Error: This transaction requires a transaction fee of at least %s because of its amount, complexity, or use of recently received funds!"
< jonasschnelli>
<*highlight>[13:50:51] <wumpus:#bitcoin-core-dev> jonasschnelli: re: https://github.com/bitcoin/bitcoin/pull/9010, any idea why not all parameter interaction was moved to InitParameterInteraction?
< wumpus>
no problem, just send a copy to bitcoin-core-dev too
< btcdrak>
please send to bitcoin-core-dev also
< wumpus>
BlueMatt: you sent the rc announcement to bitcoin-dev instead of bitcoin-core-dev :)
< cfields_>
wumpus: practically, no. Bitcoin-qt is busted on 10.7. This would just make it refuse to run there, rather than mysteriously crashing.
< GitHub175>
[bitcoin] laanwj closed pull request #8948: [TRIVIAL] reorder Windows gitian build order to match Linux (master...master) https://github.com/bitcoin/bitcoin/pull/8948
< GitHub186>
bitcoin/master e077e00 Wladimir J. van der Laan: Merge #8948: [TRIVIAL] reorder Windows gitian build order to match Linux...
< GitHub186>
bitcoin/master 3f7581d Micha: [TRIVIAL] reorder Windows gitian build order to match Linux...
< wumpus>
it also means you can make a selection "no bitcoin here, but we allow dogecoin and litecoin through!"
< wumpus>
I agree that tor or vpns are a better way to avoid more persistent firewalling, but ideally bitcoin core would get around the simple case of 'port 8333 firewalled'
< tulip>
I've been trying to work out where the regression that allows bitcoin core to attempt connections on port 0 is.
< jonasschnelli>
Though, the original 10.7 bug was reported in #bitcoin
< GitHub15>
[bitcoin] laanwj reopened pull request #8775: RPC refactoring: Never access wallet directly, only via new CRPCRequestInfo (master...multiwallet_prefactor_rpc) https://github.com/bitcoin/bitcoin/pull/8775
< murch>
gmaxwell: After Scaling Bitcoin I came up with a new algorithm. I'm still running experiments on it (and writing my evaluation chapter, thesis is due next week), but it looks pretty promising in all aspects.
< murch>
Hey gmaxwell, I was missing you at Scaling Bitcoin. :)
< gmaxwell>
nibor: majority hashpower can make their new commitment say that a million bitcoin that wasn't theirs is now theirs. Then all newly joining nodes will get the new chainstate, and eventually all old nodes will think they've hit a reorg larger than people have blocks available, and so they'll do a chainstate sync too...
< gmaxwell>
The other important thing about this proposal is that it needs to be very upfront about this being a signficant change to the Bitcoin security model, and justify it. I believe it is a nessary one.
< GitHub145>
[bitcoin] laanwj closed pull request #8993: Trivial: Fix doxygen comment: the transaction is returned in txOut (master...20161021_fix_GetTransaction_comment) https://github.com/bitcoin/bitcoin/pull/8993
< GitHub101>
bitcoin/master fd29348 Wladimir J. van der Laan: Merge #8993: Trivial: Fix doxygen comment: the transaction is returned in txOut...
< GitHub101>
bitcoin/master 1d8e12b Pavel Janík: Fix doxygen comment: the transaction is returned in txOut
< wumpus>
anyhow the problem here is that bitcoin core uses the OS's IP parsing, this has resulted in confusion before
< GitHub14>
[bitcoin] gmaxwell opened pull request #9002: Make connect=0 disable automatic outbound connections. (master...connect0) https://github.com/bitcoin/bitcoin/pull/9002
2016-10-23
< GitHub52>
[bitcoin] TheBlueMatt closed pull request #7903: Fix help text around importaddress and rename it to importscript (master...16-04-importaddress-helptext) https://github.com/bitcoin/bitcoin/pull/7903
< wumpus>
namecoin did fairly recently rebase on top of newer bitcoin core (not sure what version). But yes most coins do not, it's not like they're a big target for attacks, nor actively maintained. The only way we notice is that sometimes people file bugs/build system issues against bitcoincore that have been fixed years ago, not realizing we've moved on since
< tulip>
for a long time most alt coins were, and still are 0.6 based branches. the original proof of stake patches were never rebased onto modern Bitcoin Core until quite late in the crazy. the original lfnet IRC channels still have hundreds of alt coin nodes (but only 2-3 wxBitcoin).
< Victorsueca>
the end of the world.... as we know it and the beginning of the decentralised currency era! buy bitcoin know while your fiduciary money is still worth something!
< aj>
seems like jessie; the bitcoin.org binaries seemed to work fine for me in a chroot
< gmaxwell>
for the latter, I'm not sure what the answer is.. one option is "use bitcoin.org binaries" but if you have to compile perhaps there is a newer compiler you can install out of the next distro version without breaking things?
< wumpus>
in any case I'm going to work on GPU drivers a bit more now, still have some outstanding work to do there, maybe I can return to bitcoin with a clearer perspective
< wumpus>
I'm tired of this madness, whatever you do people are going to complain, going to disengage from bitcoin-related things for a while
< GitHub9>
[bitcoin] TheBlueMatt opened pull request #8995: Add missing cs_main lock to ::GETBLOCKTXN processing (master...2016-10-fix-getblocktxn-locks) https://github.com/bitcoin/bitcoin/pull/8995
< GitHub91>
[bitcoin] paveljanik opened pull request #8993: Trivial: Fix doxygen comment: the transaction is returned in txOut (master...20161021_fix_GetTransaction_comment) https://github.com/bitcoin/bitcoin/pull/8993
< GitHub149>
[bitcoin] instagibbs opened pull request #8992: Enable pubkey lookup for p2sh-p2wpkh in validateaddress (master...validatep2pkh) https://github.com/bitcoin/bitcoin/pull/8992
< GitHub170>
[bitcoin] laanwj closed pull request #8968: Don't hold cs_main when calling ProcessNewBlock from a cmpctblock (master...cmpctblock) https://github.com/bitcoin/bitcoin/pull/8968
< GitHub86>
bitcoin/master 3cf496d Wladimir J. van der Laan: Merge #8968: Don't hold cs_main when calling ProcessNewBlock from a cmpctblock...
< GitHub86>
bitcoin/master 72ca7d9 Matt Corallo: Don't hold cs_main when calling ProcessNewBlock from a cmpctblock
< kanzure>
there was an argument proposed where instead of only making libconsensus, someone (sipa?) said libconsensus + also some other library, and bitcoin core and also libconsensus consume from the other library.
< jtimon>
I believe some code duplication is unavoidable once bitcoin core only talks to libconsensus' C API, for example, the primitives
< wumpus>
I think this is typical bitcoin scope creep
< jtimon>
kanzure: I highly doubt libbitcoin will ever use a libconsensus that's coupled to bitcoin's storage and concurrency, for example
< jtimon>
conclusion, nobody seems to want the libconsensus I've been trying to move towards to, and as an external caller I wouldn't want a libconsensus++ (coupled to bitcoin core's storage and concurrency)
< jtimon>
BlueMatt: an interface for CBlockIndex wouldn't requiore a ton of review, just some review. Remember you can use wrappers for the old stuff and only libconsensus needs to use the interface (uppper layers can remain using CBlockIndex directly), please see https://github.com/bitcoin/bitcoin/pull/8493
< wumpus>
cfields_: right, so it's possible to fork bitcoin core but still use the same libconsensus, for example
< gmaxwell>
sorry, went to sleep during API discussions. I agree that the library should be used by bitcoin core if it is to exist. :)
< wumpus>
btw: I've had, out of many 'no' responses, only two people admitting they're still running bitcoin core on windows 32-bit. Both expect to stop doing so in the next 6 months.
< jonasschnelli>
<*highlight>[20:37:05] <sipa:#bitcoin-core-dev> jonasschnelli: ah, clocking on the warning icon. that took me a while - isn't there a way to make it more obvious, like adding another top bar with "You're currently out of sync with the network. Click here for more information' ?
< gmaxwell>
sipa: yea, I don't mean that in a dogmatic sense. And I think in bitcoin core things are usually sensible. But I've had too much exposure to codebases where novices overuse these really exotic tools.
< sipa>
cfields_: oh, so we only need to wait until 2022 until we can use it in Bitcoin Core?
< wumpus>
we *don't * want to support half of bost as part of bitcoin core
< Victorsueca>
achow101: thanks, will put that on a bitcoin block so everybody knows ;)
< GitHub21>
[bitcoin] laanwj closed pull request #8980: RPC: importmulti: Avoid using boost::variant::operator!=, which is only in newer boost versions (master...compat_importmulti_oldboost) https://github.com/bitcoin/bitcoin/pull/8980
< GitHub0>
bitcoin/master 0e22855 Wladimir J. van der Laan: Merge #8980: RPC: importmulti: Avoid using boost::variant::operator!=, which is only in newer boost versions...
< GitHub0>
bitcoin/master 7942d31 Luke Dashjr: RPC: importmulti: Avoid using boost::variant::operator!=, which is only in newer boost versions
< wumpus>
it's a valid way to do things, but that means targetting open source to windows is hard, ideally we should sell bitcoin core on windows instead of offer a free download :-)
< wumpus>
there's nothing bitcoin specific about not being able to execute the right executable
< GitHub157>
[bitcoin] jonasschnelli opened pull request #8985: Use pindexBestHeader instead of setBlockIndexCandidates for NotifyHeaderTip() (master...2016/10/fix_gui_overlay) https://github.com/bitcoin/bitcoin/pull/8985
< sipa>
NicolasDorier: there are good uses for a very powerful script interoreter that does more than consensus too... for example a debugger or execution inspector, or something that supports signing some general class of signatures, maybe not specific to bitcoin transactions, ...
< wumpus>
in any case I'm still not sure how to handle the tests in https://github.com/bitcoin/bitcoin/pull/8976 - should I skip tests that use flag combinations that are not in the API?
< GitHub167>
[bitcoin] rebroad opened pull request #8983: Show block height and size when received (master...ShowBlockHeightAndSizeWhenReceived) https://github.com/bitcoin/bitcoin/pull/8983
< GitHub133>
bitcoin/0.13 c9a5bad Wladimir J. van der Laan: doc: Update blurb in release notes...