< November 2024 >
Su Mo Tu We Th Fr Sa 12345678910 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
2017-12-05
< kallewoof>
I've been asked about address index on top of bitcoin core (to replace the unmaintained fork that exists somewhere else). What are people's opinions on this? I know some people prefer a minimal code base, but having an address index option seems like it would alleviate a lot of problems in a lot of places.
< notabot_>
RK_: bitcoin.org is the best place to start.
< notabot_>
mmhhtt: try #bitcoin channel or reddit
< mmhhtt>
#bitcoin-core-dev
< RK_>
I want to know about bitcoin
< mmhhtt>
Hello, Is there anyone knows to how can build a exchange market for other country? Is there any request from bitcoin company to me for making exc market?
< Randolf>
These servers don't have any GUI stuff installed. So I won't be able to try bitcoin-qt on them. But I could at least try bitcoin-qt on Windows 10 to confirm whether the same problem occurs cross-platform.
< achow101>
also, i'm running bitcoin-qt right now, not bitcoind
< xRavenheart>
Is anyone able to first provide me with a clear architecture diagram of bitcoin?
< xRavenheart>
E.g. For instance Bitcoin Core has optimizations 1,2 and Electrum has optimizations 3,4
< sipa>
xRavenheart: you're welcome here to ask questions about bitcoin's design and operation
< Randolf>
Dizzle: Ah, yes. I suggested that asking here may be appropriate since it might involve core development. I also suggested that they ask in the #bitcoin and ##altcoins channel.
< Dizzle>
Randolf: he's here, rejoined. I think luke-jr was just suggesting he ask elsewhere, e.g. #bitcoin
< sipa>
02:47:32 < Randolf> xRavenheart: What's your school project about? Bitcoin development?
< Randolf>
xRavenheart: What's your school project about? Bitcoin development?
2017-12-03
< gribble>
https://github.com/bitcoin/bitcoin/issues/11799 | wallet: Add compile-time checking of (non-)locking assumptions for BlockUntilSyncedToCurrentChain() [wip] by practicalswift · Pull Request #11799 · bitcoin/bitcoin · GitHub
< Provoostenator>
Tangentally related to testing the segwit branch. It looks like miners are no longer mining SegWit transactions on testnet. See my example in #bitcoin.
< bitcoin-git>
bitcoin/master 00d25e9 Wladimir J. van der Laan: Merge #11804: [docs] Fixed outdated link with archive.is...
< bitcoin-git>
bitcoin/master bf20a7d Tim Shimmin: [docs] Fixed outdated link with archive.is...
< meshcollider>
Vision: in that case, the options will be in the registry, under HKEY_CURRENT_USER\Software\Bitcoin\Bitcoin-Qt iirc
< Vision>
where are the proxy settings stored for bitcoin-qt? I cleared the proxy settings in the Options dialog, and now entering the settings dialog causes a crash. definitely a bug.
< bitcoin-git>
bitcoin/master fbce66a MarcoFalke: Merge #10493: Use range-based for loops (C++11) when looping over map elements...
< bitcoin-git>
bitcoin/master 680bc2c practicalswift: Use range-based for loops (C++11) when looping over map elements...
< gmaxwell>
and in the short term apply some mitigations in bitcoin, like increasing the FD count (ugh but I really don't like counting on FD magnitude sniffing)
< bitcoin-git>
[bitcoin] luke-jr opened pull request #11803: Bugfix: RPC/Wallet: Include HD key metadata in dumpwallet (master...bugfix_dumpwallet_hdkeypath) https://github.com/bitcoin/bitcoin/pull/11803
< Dizzle>
cfields: this abstraction on libevent or bitcoin core?
< gmaxwell>
I believe bluematt wrote a very small patch to change bitcoin to poll. We could take, that and wrap it in ifdefs so we still select on windows, and call that sub-issue done.
< wumpus>
Dizzle: I don't think it's awfully useful in bitcoin-cli anyhow though it's useful for testing (though OTOH, the patch also changed the RPC testing framework to be able to use UNIX sockets)
< wumpus>
Dizzle: do you need it to be in bitcoin-cli for that?
< gribble>
https://github.com/bitcoin/bitcoin/issues/10279 | Add a CChainState class to validation.cpp to take another step towards clarifying internal interfaces by TheBlueMatt · Pull Request #10279 · bitcoin/bitcoin · GitHub
< gribble>
https://github.com/bitcoin/bitcoin/issues/10279 | Add a CChainState class to validation.cpp to take another step towards clarifying internal interfaces by TheBlueMatt · Pull Request #10279 · bitcoin/bitcoin · GitHub
< gmaxwell>
Provoostenator: that can be resolved with a better perspective; bitcoin development is a distributed process, your effort is your contribution not the fact that it was merged, etc.
< gmaxwell>
same reason sighash flags can fail valid in bitcoin: If I pick an out of range sighash flag I could forge signatures for your pubkeys.
< gmaxwell>
prior to having the explicit versions we couldn't do that, which is why we never even merged the patch in elements, much less brought it to bitcoin.
< wumpus>
using bitcoin keys for anything else than signing transactions continues to make me uneasy
< sipa>
the original bitcoin core message signing doesn't have a bip either
< gribble>
https://github.com/bitcoin/bitcoin/issues/10279 | Add a CChainState class to validation.cpp to take another step towards clarifying internal interfaces by TheBlueMatt · Pull Request #10279 · bitcoin/bitcoin · GitHub
< andytoshi>
#bitcoin please, this is just about software development
< wordsToLiveBy>
I'm reading the bitcoin white paper, and in section 11 Satoshi gives the calculations for how you can prove with probability that an attacker can't outpace the combined processing power of the rest of the nodes, but I am not quite getting the math being used.
< eck>
are there pixmaps for bitcoin testnet? i'd like to create .desktop file for bitcoin-qt -testnet=1 that uses the green logo, instead of the orange one
< bitcoincore-slac>
Just wanted to let everyone who has committed code to bitcoin core that there are A LOT of shout-outs and appreciation to all of you the past few days on Slack, Twitter, etc. We know what you have done and continuing to do and can't thank you enough!
< Murch>
That question is better suited for Bitcoin.stackexchange.com than for this channel. However, the difficulty scales on a range of 2^256, so that scenario is pretty far-fetched.
< erichCompSci>
Hello, I was wondering about the following problem. Miners in bitcoin verify transactions in the blockchain by hashing the previous blocks header, transaction data and a nonce value. However, the block is only considered a legitimate block
< bitcoin-git>
[bitcoin] rawodb closed pull request #11787: Support for SegWit addresses, change addresses and UI request payment (master...pr/segwit_addresses_master) https://github.com/bitcoin/bitcoin/pull/11787
< BlueMatt>
sipa: if you get particularly bored, I went down a way-too-deep rabbit hole reading mapBlocksUnlinked and pruning logic, and ended up with a few teaks to help my understanding and fix some tiny edge cases as I go....care to take a look at all but the top commit on https://github.com/TheBlueMatt/bitcoin/commits/2017-11-unlinked-blockx-fixes and tell me if its worth upstreaming?
< larafale>
is UnspentTransactionOutputs only available throught REST ? I can also run that command throught bitcoin-cli I guess?
< jonasschnelli>
Masterboy: please answer in the #bitcoin channel
< sipa>
Masterboy: #bitcoin
< jonasschnelli>
blockchain: better use #bitcoin for this... off-topic here.
< blockchain>
hi I have installed bitcoin-core 15.01 and want to use the replace by fee. but the "increase transaction fee" option is grey, how can i activate it ?
< bitcoin-git>
[bitcoin] laanwj opened pull request #11783: Fix shutdown in case of errors during initialization (master...2017_11_notify_callbacks_shutdown_crash) https://github.com/bitcoin/bitcoin/pull/11783
< jonasschnelli>
raheel_: this is the core dev channel, pleae use #bitcoin or #bitcoin-dev for your Q
< wumpus>
raheel_, take this to #bitcoin
< wumpus>
raheel_: #bitcoin
< bitcoin-git>
[bitcoin] fanquake closed pull request #9859: Make TestBlockValidity optional in CreateNewBlock (master...tbv-optional) https://github.com/bitcoin/bitcoin/pull/9859
< wumpus>
this is what we should avoid: https://github.com/bitcoin/bitcoin/pull/11747 the person posts a straightforward two-line fix for an actual issue, when well-meaning but overly zealous review comments get them to refactor things in a questionable way resulting in much more discussion and doubt of correctness
< gribble>
https://github.com/bitcoin/bitcoin/issues/11389 | Support having SegWit always active in regtest (sipa, ajtowns, jnewbery) by sipa · Pull Request #11389 · bitcoin/bitcoin · GitHub
< Varunram>
rusty: aj: had the bugs few days back, turned out to be exactly what rusty specified, there'd be another .bitcoin directory somewhere. Once I changed home directories, it went well
< gmurf>
any good places to learn how to use Bitcoin api
< bitcoin-git>
[bitcoin] jnewbery opened pull request #11771: [tests] Change invalidtxrequest to use BitcoinTestFramework (master...refactor_invalidtxrequest) https://github.com/bitcoin/bitcoin/pull/11771
< bitcoin-git>
[bitcoin] joemphilips opened pull request #11770: [REST] add a rest endpoint for estimatesmartfee, docs, and test (master...rest_fee) https://github.com/bitcoin/bitcoin/pull/11770
< Randolf>
jl2012: This channel is focused on the software development aspects of bitcoin core. What you've raised seems to be a usability question, which is much more likely to be served well on the #bitcoin channel. That's why I suggested that you ask there.
< Randolf>
jl2012: Well, why don't you ask in the #bitcoin channel? Maybe it's already supported (I don't know).
< Randolf>
jl2012: You seem to be asking a question about useability rather than about development. Have you tried asking your question in the #bitcoin channel?
< bitcoin-git>
[bitcoin] aaron-hanson opened pull request #11765: [REST] added blockhash api, tests and documentation (master...rest-blockhash-endpoint) https://github.com/bitcoin/bitcoin/pull/11765
2017-11-24
< bitcoin-git>
[bitcoin] practicalswift opened pull request #11762: Avoid locking mutexes that are already held by the same thread (master...remove-double-locks) https://github.com/bitcoin/bitcoin/pull/11762
< Provoostenator>
@jonasschnelli me too, but I think a more realistic scenario is more people running Bitcoin Core nodes and connecting their favorite wallet to it.
< jonasschnelli>
I'd like to see more users using Bitcoin Core as a wallet
< jonasschnelli>
The current bitcoin wallets do loose one of the primary elements Bitcoin can defeat "Trusted third parties are security holes".
< jonasschnelli>
b) you add a script to your bitcoin core machine that would server over TLS (an RPC proxy)
< jonasschnelli>
I think long term we should not expect that private keys are on the same machine then bitcoin core runs (at least not with the current one process design)
< wumpus>
bitcoin isn't really a good project for first time open source contributors in that regard, some projects just merge everything effectively instantly, but we cannot have a policy like that, not for first contributors ither
< bitcoin-git>
[bitcoin] practicalswift opened pull request #11749: Set m_last_block_processed to nullptr in SetNull() (master...m_last_block_processed) https://github.com/bitcoin/bitcoin/pull/11749
< bitcoin-git>
[bitcoin] merehap opened pull request #11748: [Tests] Adding unit tests for GetDifficulty in blockchain.cpp. (master...blockchain_unittests) https://github.com/bitcoin/bitcoin/pull/11748
< aj>
meshcollider: mainnet bitcoin.conf and network.conf live in the same directory :(
< meshcollider>
Or would having them both called bitcoin.conf be confusing
< aj>
meshcollider: i'm not sure if there's a use case... atm, you could have standard settings in bitcoin.conf and special settings in network.conf (mainnet addnode's say), and switch either independently via command line options. that just seems a bit more flexible and maybe natural to me?
< aj>
meshcollider: i worry about that too. current behaviour is that bitcoin.conf is loaded first and network.conf second (so bitcoin.conf can specify the network), and any setting in bitcoin.conf overrides any setting in network.conf
< aj>
meshcollider: yeah: patch makes bitcoind load two config files, .bitcoin/bitcoin.conf and .bitcoin/testnet3/network.conf; -conf lets you choose a different name for the first one, -netconf a different name for the second one
< andytoshi>
Chris_Stewart_5: #bitcoin-mining will probably be more helpful, or #bitcoin. this channel is specifically about software development of Bitcoin Core
< wumpus>
also it'd make no sense, we'd have to distinguish which daemon is logging for each line - if you really want to dump all your bitcoin logging to one place, you can already use -printtoconsole w/ some log aggregation like systemd
< wumpus>
also if you just want to test w/ bitcoin and times there's setmocktime
< Sentineo>
so if I set my time to 2015 would I invalidate blocks? It sounds like bitcoin-core would take the blockchain (and other nodes) as the source of time
< bitcoin-git>
[bitcoin] laanwj closed pull request #11738: Fix sendrawtransaction hang when sending a tx already in mempool (master...2017-11-fix-sendraw-block) https://github.com/bitcoin/bitcoin/pull/11738
< bitcoin-git>
bitcoin/master d4267a3 Wladimir J. van der Laan: Merge #11738: Fix sendrawtransaction hang when sending a tx already in mempool...
< bitcoin-git>
bitcoin/master d9340ce Matt Corallo: Fix sendrawtransaction hang when sending a tx already in mempool
< Randolf>
JeffSlentz: If not, then there may be other options for you, but you'll probably need to ask about those possibilities in the #bitcoin channel.
< JeffSlentz>
Hey, as a recent grad with not much experience with the Bitcoin Core project, are there any suggestions for contributing?
< Murch>
morcos: I was just looking at fee rate estimation. I'm surprised that the Bitcoin Core estimate is still on 170 for second block target when the network has been clearing the mempool of <40 for four days.
< bitcoin-git>
[bitcoin] TheBlueMatt opened pull request #11738: Fix sendrawtransaction hang when sending a tx already in mempool (master...2017-11-fix-sendraw-block) https://github.com/bitcoin/bitcoin/pull/11738