< 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
< GitHub105>
bitcoin/master 80a7078 Wladimir J. van der Laan: Merge #8955: doc: update 0.13.0 release note info on linux arm builds...
< GitHub105>
bitcoin/master 83c0f7f mruddy: trivial: update 0.13.0 release note info on linux arm builds
< GitHub59>
[bitcoin] laanwj closed pull request #8960: doc: update 0.13.1 release note info on linux arm builds (0.13...relnote131) https://github.com/bitcoin/bitcoin/pull/8960
< GitHub192>
[bitcoin] rebroad opened pull request #8961: Headers announcement for nodes that can do headers. (master...AnnounceUsingHeaders) https://github.com/bitcoin/bitcoin/pull/8961
< GitHub117>
[bitcoin] mruddy opened pull request #8960: doc: update 0.13.1 release note info on linux arm builds (0.13...relnote131) https://github.com/bitcoin/bitcoin/pull/8960
< michagogo>
And in terms of all the libraries, if you mean the ones that go into Bitcoin Core (OpenSSL, Qt, boost, etc.), the whole beauty of the depends system is that you don't need to know about that
< jlopp>
I'm trying to better understand the purpose and future use of checkpoints in Bitcoin. My understanding is that the checkpoints are in place in order to prevent attackers from spamming nodes with low PoW block headers at low chain heights. And that a side effect of checkpoints is a performance speedup in initial block download due to skipping signature verification.
< wumpus>
michagogo: HKEY_CURRENT_USER\Software\Bitcoin\Bitcoin-Qt and HKEY_CURRENT_USER\Software\Bitcoin\Bitcoin-Qt-testnet
< GitHub53>
[bitcoin] mruddy opened pull request #8955: trivial: update 0.13.0 release note info on linux arm builds (master...relnote) https://github.com/bitcoin/bitcoin/pull/8955
< wumpus>
no, it's one 'directory' named bitcoin-qt or such
< michagogo>
If I run Bitcoin-Qt.exe with a -datadir argument, does it leave traces of itself anywhere but that directory?
< michagogo>
The win64 zip for 0.13.0 from Bitcoin.org has test_bitcoin.exe but not -qt
< michagogo>
Like I said, if you install WSL completely fresh from scratch (or for that matter, "real" Ubuntu 14.04...), those commands are everything you need to produce Bitcoin-qt.exe
< michagogo>
The ones for Bitcoin are downloaded and built by those commands