< 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
< jtimon>
dcousens: it is certainly where Bitcoin JT is headed :p
< dcousens>
I meant, that is certainly the dream, but, I don't think its where bitcoin/bitcoin is headed
< GitHub106>
[bitcoin] jrmithdobbs closed pull request #7243: This community NEEDS to adopt a code of conduct. Recent events make t… (master...code_of_conduct) https://github.com/bitcoin/bitcoin/pull/7243
< jcorgan>
blade: this is not the correct channel for this, please go to #bitcoin
< blade>
im useig the bitcoin core wallet
2015-12-21
< GitHub71>
[bitcoin] jrmithdobbs opened pull request #7243: This community NEEDS to adopt a code of conduct. Recent events make t… (master...code_of_conduct) https://github.com/bitcoin/bitcoin/pull/7243
< GitHub85>
[bitcoin] jtimon closed pull request #6625: BLOCKING: Consensus: Move blocksize and related parameters to consensusparams ...without removing consensus/consensus.h [#6526 alternative] (master...consensus-blocksize-0.12.99) https://github.com/bitcoin/bitcoin/pull/6625
< GitHub159>
[bitcoin] jtimon opened 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
2015-12-20
< GitHub4>
[bitcoin] dgenr8 opened pull request #7236: Use createrawtx locktime parm in txn_clone (master...use_rpc_locktime_clone) https://github.com/bitcoin/bitcoin/pull/7236
< maaku>
that's effectively useless given how bitcoin development works...
< jonasschnelli>
Yes. We kept bitcoin-qt because otherwise new versions would not overwrite old ones.
< jonasschnelli>
cfields: Luke-Jr's name unify PR works really good. We might want to fix the osx application name ("Bitcoin-Qt").
< GitHub173>
[bitcoin] sdaftuar opened pull request #7225: Eliminate unnecessary call to CheckBlock (master...eliminate-extra-checkblock) https://github.com/bitcoin/bitcoin/pull/7225
< cfields>
Luke-Jr: what's missing in the bitcoin build itself? the python libs?
< wumpus>
<jgarzik> benjyz1, #bitcoin-dev please
< wumpus>
off topic things not related to bitcoin development, If it fits into the above category, you're a legit contributor and somehow got 'censored' feel free to send a complaint to me
< jonasschnelli>
Luke-Jr: your TestyCOIN-Crazy projects still uses "Bitcoin-Qt.app" as filename (as you mentioned). But I guess the whole dmg process should also work if we would use a different filename? right?
< Luke-Jr>
oh, it works because we don't actually use "Bitcoin Core" in filenames