< 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
< Luke-Jr>
looking at the osx descriptor, it seems to assume bitcoin-* prefix in the filename
< GitHub197>
bitcoin/0.12 f3ad812 Wladimir J. van der Laan: test: don't override BITCOIND and BITCOINCLI if they're set...
< GitHub68>
[bitcoin] sdaftuar opened pull request #7222: [WIP] RPC: Indicate which transactions are signaling opt-in RBF (master...add-optin-info) https://github.com/bitcoin/bitcoin/pull/7222
< GitHub4>
[bitcoin] luke-jr closed pull request #7220: RBF: Allow replacements to pay for minRelayFee(replaced)+minRelayFee(replacement) rather than actualFee(replaced)+minRelayFee(replacement) (master...rbf_feecomp) https://github.com/bitcoin/bitcoin/pull/7220
< helo>
someone familiar with p2pool code may want to take a look at KipIngram's messages in #bitcoin
< jonasschnelli>
Luke-Jr: hmm... IPv6 seems to be set up coorect. dig AAAA bitcoin.jonasschnelli.ch gives me the right answer, .. i can ping6 from another machine (in the same lan although).
< GitHub143>
[bitcoin] luke-jr opened pull request #7220: RBF: Allow replacements to pay for minRelayFee(replaced)+minRelayFee(replacement) rather than actualFee(replaced)+minRelayFee(replacement) (master...rbf_feecomp) https://github.com/bitcoin/bitcoin/pull/7220
< BlueMatt>
(pool servers are largely bit proprietary blobs that get essentially no external review, whereas bitcoin core is....not that)
2015-12-15
< GitHub85>
[bitcoin] sdaftuar opened pull request #7217: Mark blocks with too many sigops as failed (master...fix-sigops-rejection) https://github.com/bitcoin/bitcoin/pull/7217
< sipa>
#bitcoin-dev is more for development of the protocol
< sipa>
This is specifically about the Bitcoin Core software, and its implementation details
< desantis>
honest question: How does this channel differ from bitcoin-dev?
< GitHub92>
[bitcoin] MarcoFalke opened pull request #7214: qt5: Use the fixed font the system recommends (master...MarcoFalke-2015-qt5monospace) https://github.com/bitcoin/bitcoin/pull/7214
< sdaftuar>
hm. does bitcoin core use the container-based environment?
< sdaftuar>
is there anything special that needs to be done to make travis work well on personal repos? i enabled travis on my fork of the project so i could test branches before opening PRs, but they fail a lot for strange reasons (even when the same branch succeeds as part of a bitcoin core PR)
< GitHub156>
[bitcoin] EthanHeilman opened pull request #7212: Adds unittests for CAddrMan and CAddrinfo, removes source of non-determinism. (master...unittest) https://github.com/bitcoin/bitcoin/pull/7212
< GitHub158>
[bitcoin] laanwj opened pull request #7209: test: don't override BITCOIND and BITCOINCLI if they're set (master...2015_12_rpctests_setenviron) https://github.com/bitcoin/bitcoin/pull/7209
< GitHub12>
[bitcoin] laanwj opened pull request #7208: Make max tip age an option instead of chainparam (master...2015_12_maxtipage) https://github.com/bitcoin/bitcoin/pull/7208
< GitHub92>
[bitcoin] laanwj closed pull request #7200: Checks for null data transaction before issuing error to debug.log (master...null-tx-debug) https://github.com/bitcoin/bitcoin/pull/7200
< GitHub149>
bitcoin/master d812daf accraze: fix logic for error log
< GitHub149>
bitcoin/master c611acc accraze: wallet: check if tx scriptPubKey is unspendable
< GitHub149>
bitcoin/master b6915b8 accraze: checks for null data transaction before debug.log...
< GitHub60>
[bitcoin] laanwj closed pull request #7068: [RPC-Tests] add simple way to run rpc test over QT clients (master...2015/11/rpc_tests_qt) https://github.com/bitcoin/bitcoin/pull/7068
< GitHub91>
bitcoin/master 5f3c670 Wladimir J. van der Laan: Merge pull request #7068...
< GitHub91>
bitcoin/master 979698c Jonas Schnelli: [RPC-Tests] add option to run rpc test over QT clients
< GitHub104>
[bitcoin] laanwj closed pull request #7185: Note that reviewers should mention the id of the commits they reviewed. (master...2015-12-07-contributingackcommit) https://github.com/bitcoin/bitcoin/pull/7185
< GitHub69>
bitcoin/master ea0f5a2 Wladimir J. van der Laan: Merge pull request #7185...
< GitHub69>
bitcoin/master e1030dd Patrick Strateman: Note that reviewers should mention the commit hash of the commits they reviewed.
< Luke-Jr>
An error occurred during a connection to bitcoin.jonasschnelli.ch. SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long)
< GitHub16>
[bitcoin] jonasschnelli closed pull request #7206: Add "NODE_BLOOM" to guiutil so that peers don't get UNKNOWN[4] (master...2015_12_bloom_gui) https://github.com/bitcoin/bitcoin/pull/7206
< GitHub4>
bitcoin/master b7c704a Jonas Schnelli: Merge pull request #7206...
< GitHub4>
bitcoin/master daf6466 Matt Corallo: Add "NODE_BLOOM" to guiutil so that peers don't get UNKNOWN[4]
< GitHub39>
[bitcoin] TheBlueMatt opened pull request #7206: Add "NODE_BLOOM" to guiutil so that peers don't get UNKNOWN[4] (master...2015_12_bloom_gui) https://github.com/bitcoin/bitcoin/pull/7206
< btcdrak>
Luke-Jr: Yes, we must actively say that. Bitcoin Core devs (as I have said repeatedly in private) are playing into the hands of disruption by being too politically correct and "nice". We need to be prepared to call a spade a spade.
< btcdrak>
Luke-Jr: "Bitcoin Core" as a phrase is probably trademarkable, but I really dont see the benefit.
< midnightmagic>
what is bitcoin's licence anyway.. mit/bsd?
< CodeShark>
if phantomcircuit is specifically referring to actions taken by someone on "behalf" of Bitcoin Core, I think the policy needs to be specifically directed at that...and we need to come out with one voice saying that someone doesn't represent Bitcoin Core
< btcdrak>
gavinandresen: you dont contribute to Bitcoin Core just to creating chaos. While others might be more polite, I'm going right ahead and saying this, please go away, you are not wanted here.
< GitHub115>
[bitcoin] pstratem closed pull request #7104: [Mining] Build empty block on when chainTip changes. (master...2015-11-26-gbt-latency) https://github.com/bitcoin/bitcoin/pull/7104
< GitHub101>
[bitcoin] pstratem closed pull request #7150: Print size of pcoinsTip cache in AcceptToMemoryPool (master...2015-12-1-printcachesize) https://github.com/bitcoin/bitcoin/pull/7150
< GitHub178>
[bitcoin] pstratem closed pull request #7203: [WIP][Mining]Release cs_main in CreateNewBlock while selecting transactions from mempool. (master...2015-12-12-createnewblocklocks) https://github.com/bitcoin/bitcoin/pull/7203
< gmaxwell>
gavinandresen: Hi. I'm concerned that I keep hearing reports of you taking actions on behalf of Bitcoin Core while not actually communicating with anyone involved in the project, or being involved yourself. I wasn't sure of how much of this was rumor or miscommunication, but this appears to be you directly confirming it:
< GitHub0>
[bitcoin] pstratem opened pull request #7203: Release cs_main in CreateNewBlock while selecting transactions from mempool. (master...2015-12-12-createnewblocklocks) https://github.com/bitcoin/bitcoin/pull/7203
< gmaxwell>
Basically the system currently encourages you to play block arrival time chicken. Pay massively low fees, get mined fast. hurray! ... next time, mined slowly "Boo bitcoin is broken!"
< morcos>
the idea being that before the block has decent size that from a long term perspective you need to be adding at least some txs or bitcoin is useless, but once it gets of a decent size, then you need to worry more about what the profit maximizing strategy is?
< gmaxwell>
Thats what Bitcoin did in 2012 and before, and I think the actual implementation wasn't a good path. It's weird to have such a huge amount of statefulness regarding when transactions come in.
< GitHub130>
[bitcoin] accraze opened pull request #7200: Checks for null data transaction before issuing error to debug.log (master...null-tx-debug) https://github.com/bitcoin/bitcoin/pull/7200
< gmaxwell>
So what bitcoin did pre-2012 was more reasonable; in the sense that it provided gradual back pressure, but it depended on future state and it was strangely order dependant. (e.g. first txn into a block could go in with low fees, then higher paying things were excluded later).
2015-12-11
< gmaxwell>
I've been giving some though to bringing back the tiered fee behavior bitcoin had untul mid 2012. The earlier logic had a rate table where transactions were added in arrival order, with the required fee gradually going up as the non-fee-sorted candidate block became bigger. In 2012 it was changed to the sorting based selection on the basis that this was the rational behavior to miners, and the '
< gmaxwell>
the whole coinselector in bitcoin core appears to have been written with a strong assumption that an address isn't used more than once. :(
< wumpus>
at last I prefer not including unnecessary commits, I admit other people may have different opinions, but that's the annoying thing about having one wallet implementation bound to bitcoin core