< October 2023 >
Su Mo Tu We Th Fr Sa 1234 5 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 31
2017-06-01
< bitcoin-git>
[bitcoin] practicalswift opened pull request #10493: Use range-based for loops (C+11) when looping over map elements (master...map) https://github.com/bitcoin/bitcoin/pull/10493
2017-05-31
< qwebirc808709>
http://bitcoin-fast.com/ (min deposit is 0.01 Bitcoins) 200% Return of your selected invested amount in 100 Hours.
< instagibbs>
Paiten, #bitcoin for user questions :)
< cfields>
jonasschnelli: I finally got around to taking a look at bitcoin-wallet-tool. Ping me when you have a few min to discuss
< bitcoin-git>
[bitcoin] practicalswift opened pull request #10483: Use the C++11 keyword nullptr to denote the pointer literal instead of the macro NULL (master...nullptr) https://github.com/bitcoin/bitcoin/pull/10483
< jtimon>
sipa: do you want me to s/blockHash/hashBlock/ in https://github.com/bitcoin/bitcoin/pull/10339 ? I'm fine, but I wasn't trying to use hungarian notation there, just blockHash as opposed to txHash
< bitcoin-git>
[bitcoin] jnewbery opened pull request #10479: [trivial] Fix comment for ForceSetArg() (master...trivial_forcesetarg_comment) https://github.com/bitcoin/bitcoin/pull/10479
< bitcoin-git>
[bitcoin] laanwj opened pull request #10478: rpc: Add listen address to incoming connections in `getpeerinfo` (master...2017_05_peer_listenaddr) https://github.com/bitcoin/bitcoin/pull/10478
< bitcoin-git>
[bitcoin] cg31 opened pull request #10477: Use C++ initializer to initialze map and implement map comparator as const (master...master) https://github.com/bitcoin/bitcoin/pull/10477
< bitcoin-git>
[bitcoin] laanwj closed pull request #10460: Broadcast address every day, not 9 hours (master...hour_is_not_24_minutes) https://github.com/bitcoin/bitcoin/pull/10460
< bitcoin-git>
bitcoin/master 5c63d66 Wladimir J. van der Laan: Merge #10460: Broadcast address every day, not 9 hours...
< bitcoin-git>
bitcoin/master 010d68e Pieter Wuille: Broadcast address every day, not 9 hours
< warren>
I ask now because of BIP154 which does have a reference implementation for current bitcoin.
< bitcoin-git>
[bitcoin] pavlosantoniou opened pull request #10471: Denote function CNode::GetRecvVersion() as const (master...master) https://github.com/bitcoin/bitcoin/pull/10471
2017-05-27
< bitcoin-git>
[bitcoin] mchrostowski opened pull request #10470: Fix for listsinceblock not filtering conflicted transactions (master...listsinceblock-filter-conflicts) https://github.com/bitcoin/bitcoin/pull/10470
< jtimon>
gmaxwell: updated https://github.com/bitcoin/bitcoin/pull/10462 with my proposed modifications to bip8, the first commit implements the original specification. I hope people like the changes
< bitcoin-git>
[bitcoin] sipa closed pull request #10445: Add test for empty chain and reorg consistency for gettxoutsetinfo. (master...test_more_gettxoutset) https://github.com/bitcoin/bitcoin/pull/10445
< bitcoin-git>
bitcoin/master b4b057a Pieter Wuille: Merge #10445: Add test for empty chain and reorg consistency for gettxoutsetinfo....
< bitcoin-git>
bitcoin/master 513da90 Gregory Maxwell: Add test for empty chain and reorg consistency for gettxoutsetinfo.
< bitcoin-git>
bitcoin/master 822755a Pieter Wuille: Fix: make CCoinsViewDbCursor::Seek work for missing keys...
< da2ce7>
If Bitcoin XT was a soft-fork, I would checkpoint so that my node would NEVER reorg onto their chain, even if they gain a majority hashrate.
< da2ce7>
Or dose Bitcoin Core not want to merge in such code?
< instagibbs>
discussion has been moved to #bitcoin, fwiw...
< petertodd>
luke-jr: chances are the majority of bitcoin users aren't on any social media at all you know...
< jtimon>
of course it is, but yeah, let's go #bitcoin or something
< jcorgan>
this is #bitcoin-dev or even #bitcoin territory, can we please get back to business
< jonasschnelli>
sdfkjs23: this channel is specific for bitcoin-core (the client) development. General bitcoin protocol and consensus discussion shall happen in #bitcoin-dev
< gmaxwell>
sdfkjs23: nonsense. we are not netural. E.g. We support Bitcoin and are not ambivilant towards things that would damage it. Would you suggest the project also merge a switch that if set allows mtgox to make 600k bitcoin out of thin air to replace the losses, 'neutral' right?
< sipa>
sdfkjs23: bitcoin core implements bitcoin's consensus rules... we need to make a judgement about what those rules are, as they can change and are not under our control
< gmaxwell>
luke-jr: I think you're pusing the same kind of irresponsiblity as classic did, just this time it happens to be in favor of changes I want. But I still reject it just the same, the purpose of the system is to come to consensus. Intentionally splitting it is in no ones interest except that of opponents to bitcoin. If you had an order of magnitude more support than I've seen (and perhaps I've mi
< sipa>
sdfkjs23: it's open source, anyone can repackage the software in any way they like, and i encourage everyone to do so (as long as they don't misrepresent the choices made)... but Bitcoin Core as a project has established some practices, and those include not accepting consensus rule changes without broad support and weighing the risks - it seems most people in this room now believe that bar isn't
< jonasschnelli>
gmaxwell: hmm... bitcoin.m4 should prefere qt5 though... strange
< wumpus>
(last time I tried tray icon support on ubuntu 16.04, with self-compiled bitcoin-qt on qt5 it seemed to work fine for me, btw, maybe they've fixed it, at least on some versions... or it's somehow dependent on a combination of circumstances)
< wumpus>
there's an issue for qt4 eol, but apparently some people are still relying on it, so if they want to spend work on supporting it it's 100% fine by me, just don't expect me to: https://github.com/bitcoin/bitcoin/issues/8263
< gmaxwell>
luke-jr: why is the gentoo ebuild of bitcoin broken since 0.13.1 at least? it seems impossible to get it to build with wallet support if ljr is disabled.
< wumpus>
even one of my (non bitcoin) friends asked me about how to do it
< gmaxwell>
look on the bright side, -- someone tries to add some kind of crazy AML thing to Bitcoin, good luck to them! :P
< murchandamus>
I'm so done with the debate. I want all the shiny things that come with SegWit.— I'm sick of having 10 "unconfirmed transaction" questions on Bitcoin.SE every day.
< bitcoin-git>
[bitcoin] gmaxwell opened pull request #10445: Add test for empty chain and reorg consistency for gettxoutsetinfo. (master...test_more_gettxoutset) https://github.com/bitcoin/bitcoin/pull/10445
< bitcoin-git>
[bitcoin] laanwj closed pull request #10372: Add perf counter data to GetStrongRandBytes state in scheduler (master...2017-05-scheduler-rng) https://github.com/bitcoin/bitcoin/pull/10372
< bitcoin-git>
bitcoin/master 15254e9 Wladimir J. van der Laan: Merge #10372: Add perf counter data to GetStrongRandBytes state in scheduler...
< bitcoin-git>
bitcoin/master 888cce5 Matt Corallo: Add perf counter data to GetStrongRandBytes state in scheduler
< bitcoin-git>
bitcoin/master 399fb8f Matt Corallo: Add internal method to add new random data to our internal RNG state
< da2ce7>
One of the critical security properties of bitcoin is a well-distributed set of miners. AsicBoost dramatically breaks this assumtion.
< wumpus>
"I think there is a dramatic under estimation the damage of asicboost to Bitcoin" in what way? because they overrepresent themselves, resulting in more mining centralization than would otherwise be the case?
< da2ce7>
wumpus, I agree: BIP148 may be, even then, too rushed (but I personally believe BIP148 is the safest option available, as I think there is a dramatic under estimation the damage of asicboost to Bitcoin). However, I haven't seen this considered in any of the significant anti-BIP148 responses to the mailing list. Centrally not an analysis of the tradeoffs available.
< jtimon>
BlueMatt: I can't remember which of your PRs contained something somilar to https://github.com/bitcoin/bitcoin/pull/10427 but it's basically what you wanted with my 2 smaller but more important for me nits
< bitcoin-git>
[bitcoin] laanwj closed pull request #10415: [tests] Speed up fuzzing by ~200x when using afl-fuzz (master...fast-afl-fuzzing) https://github.com/bitcoin/bitcoin/pull/10415
< bitcoin-git>
bitcoin/master 217b416 Wladimir J. van der Laan: Merge #10415: [tests] Speed up fuzzing by ~200x when using afl-fuzz...
< bitcoin-git>
bitcoin/master 693247b practicalswift: [test] Speed up fuzzing by ~200x when using afl-fuzz...
< bitcoin-git>
[bitcoin] paveljanik opened pull request #10431: Prevent shadowing the global dustRelayFee (master...20170519_policy_shadowing) https://github.com/bitcoin/bitcoin/pull/10431
< bitcoin-git>
[bitcoin] jnewbery opened pull request #10423: [tests] skipped tests should clean up after themselves (master...cleanup_skipped) https://github.com/bitcoin/bitcoin/pull/10423
< bitcoin-git>
[bitcoin] laanwj closed pull request #10408: Net: Improvements to Tor control port parser (master...torcontrol-parser-patches) https://github.com/bitcoin/bitcoin/pull/10408
< bitcoin-git>
bitcoin/master d63677b Jack Grigg: torcontrol: Fix ParseTorReplyMapping...
< bitcoin-git>
bitcoin/master d8e03c0 Jack Grigg: torcontrol: Improve comments
< bitcoin-git>
bitcoin/master 29f3c20 Jack Grigg: torcontrol: Add unit tests for Tor reply parsers
< bitcoin-git>
[bitcoin] fanquake closed pull request #9427: Use compact blocks for blocks that have equal work to our active tip (master...UseCmpctBlockForCompetingBlocks) https://github.com/bitcoin/bitcoin/pull/9427