< 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...
< Victorsueca>
what about this: do the docs on a separate repo, when it's release time then clone to bitcoin
< wumpus>
otherwise they can't be included with the release, they can't be uploaded to bitcoin.org and other places, etc
< wumpus>
sipa: could be, though the release notes are pretty much on the same release cycle as bitcoin core so it'd not make much of a difference
< GitHub48>
[bitcoin] s-matthew-english opened pull request #8982: Eliminating Inconsistencies in Textual Output (master...patch-6) https://github.com/bitcoin/bitcoin/pull/8982
< GitHub87>
[bitcoin] paveljanik opened pull request #8981: Wshadow: Do not shadow argument with a local variable (master...20161020_Wshadow_rpcdump) https://github.com/bitcoin/bitcoin/pull/8981
< GitHub49>
bitcoin/0.13 5f6b312 Wladimir J. van der Laan: doc: Add missing credit to release notes...
< GitHub145>
[bitcoin] luke-jr opened 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
< michagogo>
No Bitcoin private keys in there, but gpg, probably ssh, and also token for github, chrome, etc.
< jonasschnelli>
michagogo: you could turn your working system into an appliance (including your bitcoin private keys)
< GitHub135>
[bitcoin] jonasschnelli closed pull request #8775: RPC refactoring: Never access wallet directly, only via new CRPCRequestInfo (master...multiwallet_prefactor_rpc) https://github.com/bitcoin/bitcoin/pull/8775
< GitHub131>
[bitcoin] laanwj closed pull request #8788: [RPC] Give RPC commands more information about the RPC request (master...2016/09/rpc_container) https://github.com/bitcoin/bitcoin/pull/8788
< GitHub21>
bitcoin/master e7156ad Jonas Schnelli: [RPC] pass HTTP basic authentication username to the JSONRequest object
< GitHub21>
bitcoin/master 69d1c25 Jonas Schnelli: [RPC] Give RPC commands more information about the RPC request
< GitHub21>
bitcoin/master 23c32a9 Wladimir J. van der Laan: rpc: Change JSONRPCRequest to JSONRPCRequestObj...
< jonasschnelli>
wumpus: The RPC command-structure refactoring (https://github.com/bitcoin/bitcoin/pull/8788) includes your JSONRPCRequestObj renaming now. Would be nice to get this in soon to escape the rebase-hamster-wheel
< jonasschnelli>
[22:07:48] <wumpus:#bitcoin-core-dev> jonasschnelli: could you elaborate in #8546 what you mean with " I think its acceptable if it breaks wallets used back in 0.3.x in conjunction with IP transaction". I don't think it'd be acceptable if the client suddenly crashes if someone happens to be using a wallet that still has a pay-to-IP transaction in it.
< GitHub25>
[bitcoin] laanwj closed pull request #8949: Be more agressive in getting connections to peers with relevant services. (master...more_agressive_witness_connect) https://github.com/bitcoin/bitcoin/pull/8949
< GitHub181>
bitcoin/master e44753c Wladimir J. van der Laan: Merge #8949: Be more agressive in getting connections to peers with relevant services....
< GitHub181>
bitcoin/master 4630479 Gregory Maxwell: Make dnsseed's definition of acute need include relevant services....
< GitHub181>
bitcoin/master 9583477 Gregory Maxwell: Be more aggressive in connecting to peers with relevant services....
< BlueMatt>
cfields_: yea, still ready to split main and have some exciting things planned, but rather blocked on review (story of bitcoin core, i suppose...)
< gribble>
cfields was last seen in #bitcoin-core-dev 5 days, 0 hours, 12 minutes, and 27 seconds ago: <cfields> gmaxwell: for one in every X connections, we could proxy and route messages together for peer-pairs. Then they'd poison their own stats :p
< gribble>
cfields_ was last seen in #bitcoin-core-dev 4 hours, 55 minutes, and 44 seconds ago: <cfields_> yes, that one's on purpose
< GitHub52>
[bitcoin] laanwj closed pull request #8873: Add microbenchmarks to profile more code paths. (master...issue-7883-benchmarks) https://github.com/bitcoin/bitcoin/pull/8873
< GitHub196>
bitcoin/master 74dc388 Wladimir J. van der Laan: Merge #8873: Add microbenchmarks to profile more code paths....
< GitHub196>
bitcoin/master 18dacf9 Russell Yanofsky: Add microbenchmarks to profile more code paths....
< GitHub123>
[bitcoin] MarcoFalke closed pull request #8961: Headers announcement for nodes that can do headers. (master...AnnounceUsingHeaders) https://github.com/bitcoin/bitcoin/pull/8961
< michagogo>
I mean, molz in #bitcoin was installing all the actual deps, it seems
< GitHub125>
[bitcoin] jonasschnelli closed pull request #7510: Read/write bitcoin_rw.conf for exposing shared Daemon/GUI options in the GUI (master...rwconf) https://github.com/bitcoin/bitcoin/pull/7510
< GitHub148>
[bitcoin] jonasschnelli closed pull request #7107: Qt: Add network port input box to GUI settings (master...qtnetworkport) https://github.com/bitcoin/bitcoin/pull/7107
< GitHub167>
[bitcoin] jonasschnelli closed pull request #5905: [Qt][WIP] allow possibility to add a comment to a WalletTx (master...2015/03/qt_tx_comment) https://github.com/bitcoin/bitcoin/pull/5905
< jonasschnelli>
Doublecheck bitcoin.conf and -datadir (if passed in CLI)
< wumpus>
is bitcoin.conf in the right place? does it get parsed at all?
< jonasschnelli>
Should work in bitcoin.conf
< achow101>
connect= in bitcoin.conf
< wumpus>
are you using connect= in your bitcoin.conf or -connect=?
< achow101>
I found the problem. If the option is in the bitcoin.conf, it won't work. I have to put it in the command line. Any idea why?
< GitHub23>
[bitcoin] TheBlueMatt opened pull request #8968: Don't hold cs_main when calling ProcessNewBlock from a cmpctblock (master...cmpctblock) https://github.com/bitcoin/bitcoin/pull/8968
< michagogo>
20:36:24 <TD-Linux> building bitcoin under the Ubuntu for Windows environment is supported now? <-- I don't know about Support, but it does seem to work!
< wumpus>
that makes no sense, everyone is 'the bitcoin team'
< Victorsueca>
wumpus: close them all but the ones made by the bitcoin team, if anybody wants to suggest a feature tell them to first search on closed pull requests and reopen if necessary
< sipa>
you need something like 1.5 or 2 GB to compile bitcoin core, i think
< Victorsueca>
i'm stuck there and can't continue building bitcoin
< wumpus>
still, not one reply from twitter or #bitcoin from an actual user using the 32-bit windows version though. Only one person who knows someone who uses it on windows 32 bit.
< wumpus>
so, who is volunteering to do 32-bit windows testing for bitcoin core?
< Victorsueca>
also you can't use bitcoin x64 on a ia32 os tho even if your system supports x64 you may want to use ia32 OS and that would actually save a lot of memory
< gmaxwell>
Victorsueca: using bitcoin ia32 should not be considerably more memory efficient.
< Victorsueca>
What about people who has a x64 OS but has low memory and wants to use bitcoin ia32 to save memory?
< gmaxwell>
realistically, most hardware like atoms will be too non-performance to run bitcoin core anymore. :(
< TD-Linux>
gmaxwell, instead of a box in the executable that pops up, you could put it on bitcoin.org
< Victorsueca>
what about the number of downloads from bitcoin.org? that would be a good indicative of x32 usage
< wumpus>
but I have the feeling no one is using it for bitcoin core, and at least up until now responses seem to confirm that
< TD-Linux>
building bitcoin under the Ubuntu for Windows environment is supported now?
< GitHub14>
[bitcoin] laanwj closed pull request #8955: doc: update 0.13.0 release note info on linux arm builds (master...relnote) https://github.com/bitcoin/bitcoin/pull/8955