< GitHub146>
[bitcoin] jonasschnelli opened pull request #7068: [RPC-Tests] add simple way to run rpc test over QT clients (master...2015/11/rpc_tests_qt) https://github.com/bitcoin/bitcoin/pull/7068
< GitHub15>
[bitcoin] jonasschnelli opened pull request #7067: [Wallet] improve detection of conflicted transactions (master...2015/11/mempool_wallet) https://github.com/bitcoin/bitcoin/pull/7067
< GitHub86>
[bitcoin] paveljanik opened pull request #7066: [Trivial,Doc] Add missing "blocktime" description to listtransactions help, fix formatting. (master...listtransactions_blocktime) https://github.com/bitcoin/bitcoin/pull/7066
< gmaxwell>
During the last malleability attacks I walked a bitcoin ATM operator through doing that. Hard part was explaining the need, once they got it the actual implementation was easy. (well also the wallet they were using to fill their ATMs ..... had no sendmany support. :( )
< wumpus>
there's an option in bitcoin core's wallet to not spend any unconfirmed outputs
< gmaxwell>
it could cause you to overdraft yourself and rip people off accidentally and be unable to make it right (at least not immediately) because you no longer have enough bitcoin.
< GitHub122>
[bitcoin] pstratem opened pull request #7064: Perform entire CWallet::TopUpKeyPool in a transaction. (master...2015-11-19-wallet-topupkeypool) https://github.com/bitcoin/bitcoin/pull/7064
2015-11-19
< jtimon>
what's with bitcoin-cli ?
< jtimon>
does bitcoin-tx use every function defined in every cpp in util and common?
< cfields_>
yes, but see bitcoin-cli
< jtimon>
doesn't bitcoin-tx depend on both of them?
< jtimon>
in the same sense, bitcoin-tx may not require everything in util or common, but it depends on util and common as a whole
< jtimon>
assuming a future in which bitcoin core consumes libbitcoinconsensus C API directly instead of its code, that dependency will eventually happen
< cfields_>
jtimon: that's what i meant by "consensus isn't the only POV". For (bad) example, bitcoin-tx might need hashing, but not use libsecp256k1
< jtimon>
which reminds me...I need to ask cfields what would he think about a consensus building module separated from util, common, etc, maybe merging with libsecp256 and crypto modules (that is not good for bitcoin-tx when we start adding non-tx stuff to the module, but verifyheader and verifyblock should be relatively light compared to verifytx and verifyscript)
< sipa>
hmm, do we have any means for people to select pruning at first run of Bitcoin-Qt?
< GitHub67>
[bitcoin] sdaftuar opened pull request #7063: [Tests] Add prioritisetransaction RPC test (master...add-prioritisetransaction-rpctest) https://github.com/bitcoin/bitcoin/pull/7063
< GitHub36>
[bitcoin] sdaftuar opened pull request #7062: [Mempool] Fix mempool limiting for PrioritiseTransaction (master...fix-mempool-limiting) https://github.com/bitcoin/bitcoin/pull/7062
< sipa>
jgarzik: it seems that that is not really the case; you can come up with a formula to treat bitcoin-days-destroyed as extra fee, but it's probably hard to prevent it from making miners lose large amounts in fees
< wumpus>
the wallet code gives me a headache. I tried to explain https://github.com/bitcoin/bitcoin/issues/7054 (Difference in getbalance and sum(listtransactions) amounts (testnet)) but failed
< wumpus>
but I agree that you either want bitcoin core to choose a fee for you (estimate confirm within # confirmations) or you want to set a fee/kB, which should be above what your mempool accepts at all
< MarcoFalke>
wumpus, about the "all fees in bitcoin core are per kB" thing:
< GitHub9>
[bitcoin] laanwj opened pull request #7060: doc: Make networking work inside builder in gitian-building.md (master...2015_11_gitian_building) https://github.com/bitcoin/bitcoin/pull/7060
< GitHub150>
bitcoin/master 2e31d74 Wladimir J. van der Laan: gitian: use trusty for building
< wumpus>
there's one difference though: tor only authenticates on opening the connection, bitcoin http authenticates for every request. So they can use more key stretching without creating command latency issues.
< Greyboy>
instagibbs, i know i'm new and my opinion is relatively worthless, but i think it's a good idea. my question is what percent of people who run bitcoin-core actually need this solution?
< GitHub111>
[bitcoin] jtimon opened pull request #7053: Globals: Remove a bunch of Params() from main.cpp before 0.12 (master...globals-chainparams-main) https://github.com/bitcoin/bitcoin/pull/7053
< GitHub184>
[bitcoin] MarcoFalke opened pull request #7052: [qa] python-bitcoinrpc is no longer a subtree (master...MarcoFalke-2015-qaSubtree) https://github.com/bitcoin/bitcoin/pull/7052
< GitHub23>
[bitcoin] laanwj opened pull request #7051: ui: Add "Copy raw transaction data" to transaction list context menu (master...2015_11_transaction_hex2) https://github.com/bitcoin/bitcoin/pull/7051
< gmaxwell>
Okay, I confess some paranoia here-- I don't want this to be like the rpc hangs issue. Where we pigheadily avoid improvements for some silly footgun which is making people stop using bitcoin core and switch to hosted apis.
< GitHub150>
[bitcoin] fanquake opened pull request #7048: [doc][trivial] Update miniupnpc version in build-unix (master...miniupnpc-build-unix) https://github.com/bitcoin/bitcoin/pull/7048
< gmaxwell>
As far as I know the normal relay network bitcoin nodes do nothing special on the bitcoin p2p protocol.
< GitHub144>
[bitcoin] luke-jr opened pull request #7047: [WIP] Backports for 0.11.3 (updated to e8df8a5) (0.11...backports-for-0.11.3) https://github.com/bitcoin/bitcoin/pull/7047
< BlueMatt>
morcos: sorry, I've been behind on bitcoin core...people were starting to notice the relay network had been broken for a long time so i figured i needed to fix it
< GitHub102>
[bitcoin] pstratem opened pull request #7046: [WIP] Net: Ignore "tx" messages in blocks only mode. (master...2015-11-17-blocksonly) https://github.com/bitcoin/bitcoin/pull/7046
< GitHub121>
[bitcoin] luke-jr opened pull request #7045: Bugfix: Use unique autostart filenames on Linux for testnet/regtest (master...linux_autostart_unique) https://github.com/bitcoin/bitcoin/pull/7045
< GitHub126>
[bitcoin] instagibbs opened pull request #7044: RPC: Added additional config option for multiple RPC users. (master...multrpc) https://github.com/bitcoin/bitcoin/pull/7044
< GitHub93>
[bitcoin] laanwj closed pull request #7020: Implement helper class for CTxMemPoolEntry constructor (master...EntryHelper) https://github.com/bitcoin/bitcoin/pull/7020
< GitHub86>
bitcoin/master e8df8a5 Wladimir J. van der Laan: Merge pull request #7020...
< GitHub86>
bitcoin/master e587bc3 Alex Morcos: Implement helper class for CTxMemPoolEntry constructor...
< wumpus>
(or #bitcoin-wizards if it is moonmath related :-) )
< wumpus>
well definitely not here, this channel is just for bitcoin core related programming work. The proper answer to your question is stil 'the mailing list'. #bitcoin-dev is fine, but IRC discussion tends to be more ephermal than mailing lists
< CodeShark>
The usual procedure for BIP proposals is to discuss on mailing list first. But given that at least a few important reviewers/critics either have unsubscribed to the ML entirely or else just ignore it, should we discuss it here or in bitcoin-dev?
< GitHub155>
[bitcoin] MarcoFalke opened pull request #7030: [contrib] Delete test-patches and move testgen to devtools (master...MarcoFalke-2015-contribC) https://github.com/bitcoin/bitcoin/pull/7030
< GitHub151>
[bitcoin] sdaftuar opened pull request #7029: Remove unmaintained example test script_test.py (master...script-test-cleanup) https://github.com/bitcoin/bitcoin/pull/7029
< GitHub162>
[bitcoin] MarcoFalke opened pull request #7028: [doc] qa: Move README.md and update -help (master...MarcoFalke-2015-qaReadme) https://github.com/bitcoin/bitcoin/pull/7028
< sipa>
also, it may not be exploitable... the BN_sqr bug we found in OpenSSL (thanks to libsecp256k1's unit tests that compared with OpenSSL) was technically a hard fork for bitcoin when it got foxed, but an unexploitable one as far as we know
< GitHub113>
bitcoin/master e54ebbf Wladimir J. van der Laan: Merge pull request #6954...
< GitHub113>
bitcoin/master 6e18268 Pieter Wuille: Switch to libsecp256k1-based validation for ECDSA
< GitHub159>
[bitcoin] MarcoFalke opened pull request #7027: [qa] rpc-tests: Properly use test framework (master...MarcoFalke-2015-rpcTestCleanup) https://github.com/bitcoin/bitcoin/pull/7027
< GitHub43>
[bitcoin] MarcoFalke opened pull request #7026: [contrib] Update versionprefix to "bitcoin-core" in verify.sh (master...MarcoFalke-2015-verify) https://github.com/bitcoin/bitcoin/pull/7026
< GitHub134>
bitcoin/master dafefb7 Wladimir J. van der Laan: Merge pull request #7016...
< GitHub72>
[bitcoin] laanwj closed pull request #7016: Avoid a compile error on hosts with libevent too old for EVENT_LOG_WARN. (master...without_EVENT_LOG_WARN) https://github.com/bitcoin/bitcoin/pull/7016
< GitHub134>
bitcoin/master aee22bf Gregory Maxwell: Avoid a compile error on hosts with libevent too old for EVENT_LOG_WARN....
< wumpus>
BTW: if you get "/home/user/bitcoin/src/key.cpp:204: undefined reference to `secp256k1_ecdsa_sign_recoverable'" errors after updating to master you need to clean your git tree (since #6983)
< GitHub45>
[bitcoin] jonasschnelli opened pull request #7025: [Qt] refactor and optimize proxy settings behavior (master...2015/11/qt_settingsvalidation) https://github.com/bitcoin/bitcoin/pull/7025
< GitHub193>
bitcoin/0.11 595c8d6 Wladimir J. van der Laan: Merge pull request #7021...
< GitHub193>
bitcoin/0.11 9730051 Alex Morcos: add bip65 tests to rpc-tests.sh -extended
< GitHub34>
[bitcoin] laanwj closed pull request #7021: add bip65 tests to rpc-tests.sh -extended (in 0.11 branch) (0.11...11rpcfixups) https://github.com/bitcoin/bitcoin/pull/7021
< GitHub101>
[bitcoin] gmaxwell closed pull request #6991: Minor: Clarify 'fee' field in fundrawtransaction help text (master...clarify-fundrawtransaction-help) https://github.com/bitcoin/bitcoin/pull/6991
< GitHub194>
bitcoin/master 9bd3f03 Peter Todd: Clarify 'fee' field in fundrawtransaction help text...
< gmaxwell>
for me bitcoin core sync runs at around 8000tx/s (with secp256k1), even though every tx is involving a non-cachable missing record check for bip30 (in addition to all the cached stuff)... thats really quite remarkable IMO.
< gmaxwell>
FWIW, I've unsubscribed from bitcoin-dev mailing list.
< gmaxwell>
yes, not a risk for us but we'll probably get asked to update when people notice bitcoin-qt links it.
< GitHub184>
[bitcoin] morcos opened pull request #7020: Implement helper class for CTxMemPoolEntry constructor (master...EntryHelper) https://github.com/bitcoin/bitcoin/pull/7020
< gmaxwell>
Well it's also a bit #bitcoin-core-dev too, in that I think it would be useful if work were done in the GUI to make mining fun, ... but probably more than that is just speculation :)
< gmaxwell>
also it suggests a framework for setting minimum feerates which are independant of bitcoin's price-- though dependant on communications efficiency, which is perhaps no better. :)
< GitHub50>
[bitcoin] morcos closed pull request #6292: Rename and comment priority calculation in TxMemPoolEntry (master...PriorityComment) https://github.com/bitcoin/bitcoin/pull/6292
< GitHub101>
[bitcoin] gmaxwell opened pull request #7016: Avoid a compile error on hosts with libevent too old for EVENT_LOG_WARN. (master...without_EVENT_LOG_WARN) https://github.com/bitcoin/bitcoin/pull/7016
< gmaxwell>
morcos: the relay network has its own protocol, and a local proxy you run that speaks bitcoin p2p.
< tulip>
morcos: there's also stratum proxies like bfgminer and stratum-mining-proxy which present work to downstream miners, based on either an upstream work server or a Bitcoin node. the latter was meant for use with early hardware miners which supported getwork but not stratum.
< gmaxwell>
(Forrestv seems to have flamed out due to a mixture of bitcoin drama, and then donations to support p2pool being relatively low (compared to life changing amounts of income centeralized pool operators were getting), and then he got ripped off ... twice, I think, by mining hardware makers.)
< gmaxwell>
Also through this time the developer burned out on Bitcoin, and only does life support maintaince on p2pool now.
< gmaxwell>
P2pool is nice idea with cute features, but has always struggled with the high startup cost of having to run a bitcoin node with it; and then high latency asics showed up (in particular, some of the early BFL products had 10%+ hashrate loss from 10 second retasking)
< gmaxwell>
morcos: well it's armored by bitcoin nodes in and out; not that there haven't been problems.
< gmaxwell>
Yes. It is. I tried to do it for bitcoin core eons ago, but the utility library was GPLed... they since changed the licensing.
< wumpus>
sure that's why I dont give "integrate it into bitcoin core" as an alternative, but say communicate through a pipe or socket
< gmaxwell>
But the biggest reason for the seperate process is to tear down development barriers. E.g. so someone can build a module without the scarryness in bitcoin core. :)
< GitHub21>
[bitcoin] jonasschnelli opened pull request #7006: [Qt] add startup option to reset Qt settings (master...2015/11/qt_resetsettings) https://github.com/bitcoin/bitcoin/pull/7006
< GitHub147>
[bitcoin] jgarzik opened pull request #7005: Add MAINTAINERS file, a user guide to code subsystems (master...2015_maintainer) https://github.com/bitcoin/bitcoin/pull/7005
< jonasschnelli>
[12:41:14] <Luke-Jr>jonasschnelli: why a new key? :/ <-- the new key is not really new, It's just the one that I use for bitcoin-dev posts, etc. The "old" key is used for non-bitcoin software-projects (and sadly, i have used it for gitian signatures)
< CodeShark>
if I whitelist a node, other than network/transport issues or misbehaving, is there ever any conceivable situation where the node could get disconnected by bitcoin core