< June 2023 >
Su Mo Tu We Th Fr Sa 12345 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30
2017-12-06
< hkjn0>
hm, right. so I guess that L1289-1290 in bitcoin's configure.ac would be where to pass through the config flags to secp256k1: AC_CONFIG_SUBDIRS([src/secp256k1])
< wumpus>
the only documentation of it is in ./configure. secp256's configure at that, not bitcoin's.
< bitcoin-git>
bitcoin/master 434526a Karl-Johan Alm: [test] Add tests for getrawtransaction with block hash.
< bitcoin-git>
bitcoin/master b167951 Karl-Johan Alm: [rpc] Allow getrawtransaction to take optional blockhash to fetch transaction from a block directly.
< BlueMatt>
spudowiar: lots of folks seem like the "bitcoin has a p2p network, lets shove more features in it so that *everything* can use it!" approach, cause its easy, but it also doesnt scale....ultimately the bitcoin p2p network is full of garbage evil nodes anyway, its not magic...
< bitcoin-git>
[bitcoin] TheBlueMatt opened pull request #11834: [verify-commits] Fix gpg.sh's echoing for commits with '\n' (master...2017-12-verify-commits-fix) https://github.com/bitcoin/bitcoin/pull/11834
< bitcoin-git>
[bitcoin] TheBlueMatt opened pull request #11831: Always return true if AppInitMain got to the end (master...2017-12-startup-exit-return-code-race) https://github.com/bitcoin/bitcoin/pull/11831
< bitcoin-git>
[bitcoin] MeshCollider opened pull request #11829: Test datadir specified in conf file exists (master...201712_datadir_crash) https://github.com/bitcoin/bitcoin/pull/11829
< kallewoof>
I guess I'll try linking directly and see how far that gets me. I suspect there will be a lot of issues where the bitcoin code expects a fully fledged bitcoin instance running.
< kallewoof>
Hum. I could avoid a lot of reinventing wheels by simply requiring libbitcoin_[x].a in the indexer to link p2p stuff in. Potential minefield, but would be super easy to keep up to date with bitcoin core if it worked.
< kallewoof>
And yeah, we agreed this should be an external thing that either uses hooks in bitcoin or implements the p2p protocol and talks to the network directly.
< gribble>
https://github.com/bitcoin/bitcoin/issues/10275 | [rpc] Allow fetching tx directly from specified block in getrawtransaction by kallewoof · Pull Request #10275 · bitcoin/bitcoin · GitHub
< Randolf>
esotericnonsense: For Bitcoin stuff, I'd create custom datatypes that save the data in binary format.
< kallewoof>
I think having hooks in bitcoin core that let such a system exist separately is a good plan. It would only rely on API breakage, which bitcoin core is very careful about.
< 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