< December 2023 >
Su Mo Tu We Th Fr Sa 12
3 4 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
2016-01-08
< GitHub174>
[bitcoin] theuni opened pull request #7322: c++11: add scoped enum fallbacks to CPPFLAGS rather than defining them locally (master...c++11-prep) https://github.com/bitcoin/bitcoin/pull/7322
< GitHub85>
[bitcoin] jonasschnelli opened pull request #7319: [Backport 0.12][QT] Intro: Display required space (0.12...2016/01/bp_qtintrodatadirsize) https://github.com/bitcoin/bitcoin/pull/7319
< GitHub110>
[bitcoin] jonasschnelli opened pull request #7318: Backport: quickfix for RPC timer interface problem (0.12...2016/01/bp_rpctimerinterface) https://github.com/bitcoin/bitcoin/pull/7318
< jonasschnelli>
sorry, sorry, MarcoFalke just told me the fact that i did push branches to bitcoin/bitcoin, will delete them immediately! that git beast!
< Luke-Jr>
so we also need to include bitcoin-config.h before that
< Luke-Jr>
cfields: why are you defining FORCE_BOOST_EMULATED_SCOPED_ENUMS in bitcoin-config.h rather than BOOST_NO_SCOPED_ENUMS and BOOST_NO_CXX11_SCOPED_ENUMS ?
< cfields>
i think just patching boost in-place with that and rebuilding bitcoin should do it, no need to rebuild boost
< Luke-Jr>
Bitcoin source or boost?
< Yoghur114_2>
phantomcircuit: ok I've identified the confusion more precisely (for the record): it was a git thing. What I didn't understand was why a 0.11.2 build didn't trigger this test: https://github.com/bitcoin/bitcoin/blob/master/configure.ac#L717 - which I thought was added january 20th of 2015 according to the history, however, that commit was part of a PR that only got merged into master last september - after master branched off from .11
< GitHub59>
[bitcoin] jtimon opened pull request #7311: MOVEONLY: non-consensus: from pow to chain: (master...consensus-pow-moveonly-0.13.99) https://github.com/bitcoin/bitcoin/pull/7311
< GitHub180>
[bitcoin] jtimon opened pull request #7310: MOVEONLY: Move consensus functions out of main (master...consensus-moveonly-0.13.99) https://github.com/bitcoin/bitcoin/pull/7310
< jtimon>
MarcoFalke: unless I'm missing something, Luke-Jris just tired of rebasing and wants to do it only one last time before Bitcoin Core is ready to accept his patch
< GitHub122>
[bitcoin] jtimon closed pull request #7238: Blocksize: Some small preparations for a blocksize hardfork (master...6526-6625-remainings-0.13.99) https://github.com/bitcoin/bitcoin/pull/7238
< GitHub163>
[bitcoin] laanwj closed pull request #7257: Combine common error strings for different options so translations can be shared and reused (master...reduce_opt_ts) https://github.com/bitcoin/bitcoin/pull/7257
< GitHub110>
bitcoin/master de9e5ea Wladimir J. van der Laan: Merge pull request #7257...
< GitHub110>
bitcoin/master 5e10922 Luke Dashjr: Combine common error strings for different options so translations can be shared and reused
< Luke-Jr>
morcos: for an example using real-world terms, say I merge the "Unify name" PR into Bitcoin LJR yesterday; and now I rebase it for Core master. Trying to merge this rebased branch into Bitcoin LJR will not work, even after I merge Core master into LJR, because the rebased branch conflicts with the pre-rebase branch
< morcos>
imagine someone has some external program that does their own fee estimation. And they use settxfee to tell bitcoin core what fee to pay based on that
< GitHub105>
[bitcoin] laanwj closed pull request #7217: Mark blocks with too many sigops as failed (master...fix-sigops-rejection) https://github.com/bitcoin/bitcoin/pull/7217
< GitHub141>
bitcoin/master a10a792 Wladimir J. van der Laan: Merge pull request #7217...
< GitHub141>
bitcoin/master 5246180 Suhas Daftuar: Mark blocks with too many sigops as failed
< morcos>
I'm asking this because I think we should change the default value that gets used if fee estimation can't give you an answer. As rusty was pointing out in bitcoin-dev, 1000 sat/KB is just too small
2016-01-04
< GitHub1>
[bitcoin] MarcoFalke opened pull request #7293: [wallet] Add regression test for vValue sort order (master...Mf1601-wallet-vValue) https://github.com/bitcoin/bitcoin/pull/7293
< GitHub151>
[bitcoin] sdaftuar closed pull request #7222: [WIP] RPC: Indicate which transactions are signaling opt-in RBF (master...add-optin-info) https://github.com/bitcoin/bitcoin/pull/7222
< GitHub199>
[bitcoin] sdaftuar opened pull request #7292: [RPC] Expose ancestor/descendant information over RPC (master...add-chain-info) https://github.com/bitcoin/bitcoin/pull/7292
< GitHub179>
[bitcoin] EthanHeilman opened pull request #7291: Add CNetAddr and CService tests demonstrating constructor differences (master...cservice) https://github.com/bitcoin/bitcoin/pull/7291
< GitHub131>
[bitcoin] luke-jr opened pull request #7289: [WIP] Make arguments reconfigurable at runtime via RPC (master...rpc_setarg) https://github.com/bitcoin/bitcoin/pull/7289
< GitHub191>
[bitcoin] jtimon opened pull request #7287: Consensus: Remove calls to error(), FormatStateMessage() and FormatMoney() (master...consensus-decouple-util-0.13.99) https://github.com/bitcoin/bitcoin/pull/7287
< vojtik>
i have bitcoin core, and it generate me adress for income bitcoin, but in this moment i can this adress find, cant find money, anythink,,, just have link for block chain
< GitHub184>
bitcoin/0.12 3cb066c Wladimir J. van der Laan: Update translations after #7253...
< GitHub13>
bitcoin/0.12 a75a03a Luke Dashjr: Bugfix: update-translations: Allow numerus translations to omit %n specifier (usually when it only has one possible value)...
< GitHub22>
[bitcoin] laanwj closed pull request #7253: Bugfix: update-translations: Allow numerus translations to omit %n specifier (usually when it only has one possible value) (master...numerus_omit_n) https://github.com/bitcoin/bitcoin/pull/7253
< GitHub169>
bitcoin/master 45d13ab Wladimir J. van der Laan: Merge pull request #7253...
< GitHub169>
bitcoin/master 0d59589 Luke Dashjr: Bugfix: update-translations: Allow numerus translations to omit %n specifier (usually when it only has one possible value)
< GitHub113>
[bitcoin] laanwj closed pull request #7251: [0.12] gitian: Set reference date to something more recent (0.12...MarcoFalke-2015-gitianTime-0.12) https://github.com/bitcoin/bitcoin/pull/7251
< GitHub193>
bitcoin/master eb2b745 Wladimir J. van der Laan: Merge pull request #7251...
< GitHub193>
bitcoin/master fa09562 MarcoFalke: [gitian] Set reference date to something more recent
< aj>
phantomcircuit: (assuming: no external profits, eg shorting bitcoin on a different exchange; and the cost of creating a hash of an invalid block is the same as for a valid block -- if PoW was changed so you could produce a hash that simultaneously attested to a good and a bad block, that'd change)
< petertodd>
dgenr8: I'm working on a document actually to set design criteria - a major one is the hashing power in adttendance at scaling bitcoin came to consensus that under attack conditions the orphan rates of largest and smallest pools should vary no more than +- 0.5%
< dgenr8>
[15-12-28 19:39:52] <petertodd> sipa: the blocksize limit needs to be kept low enough to keep that from being a major problem; if the ecosystem wants to go elsewhere, I'm leaving bitcoin development, and so should the rest of you
< petertodd>
maaku: heck, even in treechains you still need to force miners to actually have blockchain data for the system to work - bitcoin is at its core a proof-of-publication system, and the only thing forcing miners to publish right now is validation
< petertodd>
if startinga new pool is ever difficult (assuming enough hashing power joins to keep variance reasonable) then we've failed and the system we have isn't bitcoin as we know it
< petertodd>
sipa: the blocksize limit needs to be kept low enough to keep that from being a major problem; if the ecosystem wants to go elsewhere, I'm leaving bitcoin development, and so should the rest of you
< jayd3e>
so, I'm finding the bitcoin-core code pretty dense, it does a lot of things and is configured for a number of different platforms
< GitHub179>
[bitcoin] dooglus opened pull request #7262: Reduce inefficiency of GetAccountAddress() (master...faster-getaccountaddress) https://github.com/bitcoin/bitcoin/pull/7262
2015-12-28
< petertodd>
sipa: bitcoin has very strongly *defined* transaction finality: at a given # of confirmations from a point after which you're sure is in the longest chain, you know exactly what it'dcost to reorganize
< sipa>
but bitcoin doesn't have the strong transaction finality either as such
< sipa>
petertodd: "lull you into an ecosystem without strong transaction finality"... isn't that already the case for bitcoin? you never know that the block you saw may be reorganized away
< petertodd>
sipa: the alternative isn't that, it's that we scale up bitcoin differently
< petertodd>
sipa: well, the fact that you can do that is probably a flaw in the bitcoin protocol
2015-12-27
< phantomcircuit>
Luke-Jr, "Bitcoin" and "Bitcoin Core" should not be translated, they are proper names
< GitHub25>
[bitcoin] luke-jr opened pull request #7257: Combine common error strings for different options so translations can be shared and reused (master...reduce_opt_ts) https://github.com/bitcoin/bitcoin/pull/7257
< GitHub82>
[bitcoin] fanquake opened pull request #7256: Remove QT5 workaround from coin control dialog (master...remove-qt5-fix-ccontrol) https://github.com/bitcoin/bitcoin/pull/7256
< GitHub176>
[bitcoin] fanquake opened pull request #7255: Replace some instances of formatWithUnit with formatHtmlWithUnit (master...bitcoinunits-format) https://github.com/bitcoin/bitcoin/pull/7255
2015-12-25
< GitHub47>
[bitcoin] luke-jr opened pull request #7253: Bugfix: update-translations: Allow numerus translations to omit %n specifier (usually when it only has one possible value) (master...numerus_omit_n) https://github.com/bitcoin/bitcoin/pull/7253
< GitHub54>
[bitcoin] MarcoFalke opened pull request #7252: [gitian] Set reference date to actual release date (master...MarcoFalke-2015-gitianTime-0.13) https://github.com/bitcoin/bitcoin/pull/7252
< GitHub80>
[bitcoin] MarcoFalke opened pull request #7251: [0.12] gitian: Set reference date to actual release date (0.12...MarcoFalke-2015-gitianTime-0.12) https://github.com/bitcoin/bitcoin/pull/7251
2015-12-24
< GitHub140>
[bitcoin] MarcoFalke opened pull request #7250: [qa] Move gen_return_txouts() to util.py (master...MarcoFalke-2015-rpcUtilReturnTxouts-0.12) https://github.com/bitcoin/bitcoin/pull/7250
2015-12-23
< GitHub11>
[bitcoin] jonasschnelli closed pull request #7214: qt5: Use the fixed font the system recommends (master...MarcoFalke-2015-qt5monospace) https://github.com/bitcoin/bitcoin/pull/7214
< GitHub60>
bitcoin/master be9a9a3 Jonas Schnelli: Merge pull request #7214...
< GitHub60>
bitcoin/master fa2f4bc MarcoFalke: qt5: Use the fixed font the system recommends
< wumpus>
<maaku> I would also question the "but that makes altcoins easier!" argument -- who cares? -- but I know that would fall on deaf ears <- yes, who cares, I'd rather have people that disagree on fundamental properties of bitcoin working on altcoins than staying around here to troll
< morcos>
wangchun: Not sure if this is related to the issue you were describing, but very recently a fix to the way PrioritiseTransaction works was merged: https://github.com/bitcoin/bitcoin/pull/7062
< Luke-Jr>
the goal here is to make it easier to rename and/or fork Core, but within the scope of Bitcoin
< jonasschnelli>
maaku: i think Luke-Jr's PR does not change the binary names itself (like bitcoin-cli stays bitcoin-cli)
< Luke-Jr>
warren: sidechains are Bitcoin
< maaku>
and there's still a few places that need to be parameterized, like bitcoind/bitcoin-cli in the RPC help text
< maaku>
my experience is that there are a few spots you don't want to search-replace however, such as references to the Bitcoin Wiki
< warren>
Can we go further and parameterize all variations of the word Bitcoin in various strings that are currently translated?
< maaku>
anyway I think the proposed plan is good -- hard-code "The Bitcoin Core Developers" in #7192, and then later PR a bike-sheddable extended copyright notice for non-Bitcoin Core implementations
< warren>
maaku: FWIW, Litecoin added a second copyright instead of renaming "Bitcoin developers" as renaming would be disrespectful and probably a copyright violation.
< warren>
wumpus: I suggested parameterizing the name "Bitcoin" everywhere in part to make the overall delta of a sidechain fork far smaller.
< maaku>
this is fixable, but for now just don't substitute "Bitcoin Core" in the copyright string
< MarcoFalke>
Luke-Jr, it implies that, imo. Imagine MF Core is some fancy bitcoin app with the whole gui changed but running bitcoin core in the background. The only copyright notice says "(c) MF core developers". This clearly implies MF core developers are the only authors of the app.
< wumpus>
having it automatically substituted only makes sense for Bitcoin Core, derivative projects likely want to extend it instead
< Luke-Jr>
maaku: from Bitcoin Core *developers* -> Liquid *developers*
< maaku>
Luke-Jr: (1) changing copyright from Bitcoin Core -> Liquid; (2) Should be Blockstream in this context anyway --- "Copyright 2009-2016 The Bitcoin Core Developers; Copyright 2015-2016 Blockstream"
< MarcoFalke>
Luke-Jr, not everyone preserves git history and the binaries are often distributed without the source code, so there'd be no way to find out if "MF core developers" actually include the bitcoin core developers as well
< maaku>
I think he meant to highlight me -- I was pointed out that e.g. if I use this patch to change Bitcoin Core -> Liquid, the Liquid documentation would say "Copyright 2009-2015 The Liquid Developers" which is wrong in at least two ways
< wumpus>
yes, it's supposed to be Bitcoin Core developers - was it changed back somehow?
< Luke-Jr>
MarcoFalke: btw, re copyright display, note we've changed it from Bitcoin developers to Bitcoin Core developers already once :P
< wumpus>
imo there's just too little time left, at least I don't have a lot of time to spend on bitcoin the remainder oft this year
< GitHub83>
bitcoin/master 595f939 Wladimir J. van der Laan: Merge pull request #7213...
< GitHub83>
bitcoin/master 37d271d mb300sd: Rename OP_NOP2 to OP_CHECKLOCKTIMEVERIFY.
< GitHub25>
bitcoin/master 9b41a5f Suhas Daftuar: Add more tests to p2p-fullblocktest
< maaku>
wangchun: no matter your parameters. bitcoin usage will grow to exceed capacity. this is the expected outcome
< jtimon>
in fact, I believe I will just remove the free tx special case from bitcoin-consensus-policy-jt, so it doesn't beelong in the bitcoin-policy-luke-jt common branch
< jtimon>
the goal of bitcoin-policy could be to support the most interesting ones that are relatively easy to rebase from the latest major release, or that can be easily added in the current one
< jtimon>
let's not support it on github/bitcoin, but it would be good that people understand that is going to be supported anyway, even if they don't like that
< jtimon>
Luke-Jr: that shouldn't be an impediment, bitcoin-policy can be just the subset of bitcoin JT related to policy that you are happy with when you have time to be happy with it, not in a hurry for review anymore since this is going to be on top of 0.12 instead of master (I don't plan to PR anything policy-related until all the consensus code is encapsulated in a single building module independent from storage in master)
< sipa>
Luke-Jr: once they do, i'm sure we can even discuss it as default policy in bitcoin core
< jtimon>
sipa: now we're talking about our potential collaboration (or Bitcoin JT if Luke-Jr cannot commit to the "nit early, nit often" principle) in which I'm interested in exposing as many policies as possible (just to prove the reusability of the underlying Cpolicy interface)
< jtimon>
btcdrak: sipa: ok, but let's not make another bool please, let's do -policy=firstseen -policy=optinrbf even if bitcoin core insists on having people like petertodd publishing parallel releases
< jtimon>
if you want to collaborate with me on this bitcoin-policy branch you'll have to learn to nit faster, because I already have Bitcoin Core for when I'm fine waiting
< jtimon>
I would be happy to collaborate with you in bitcoin-policy if that makes sense to you
< Luke-Jr>
jtimon: any interest in combining efforts perhaps BTW? maybe Bitcoin LJR + Bitcoin JT can merge to some not-so-personal name?
< jtimon>
Luke-Jr: I think he means bitcoin core did the promise, not the protocol
< jtimon>
it will be cleaner for me to add the -policy=fullrbf option in bitcoin JT 0.12
< jtimon>
ok, but let's not make another bool please, let's do -policy=firstseen -policy=optinrbf even if bitcoin core insists on having people like petertodd publishing parallel releases