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?
oh, it works because we don't actually use "Bitcoin Core" in filenames
looking at the osx descriptor, it seems to assume bitcoin-* prefix in the filename
bitcoin/0.12 f3ad812 Wladimir J. van der Laan: test: don't override BITCOIND and BITCOINCLI if they're set...
[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
someone familiar with p2pool code may want to take a look at KipIngram's messages in #bitcoin
[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
hm. does bitcoin core use the container-based environment?
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)
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.
Luke-Jr: "Bitcoin Core" as a phrase is probably trademarkable, but I really dont see the benefit.
what is bitcoin's licence anyway.. mit/bsd?
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
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.
[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
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:
[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
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!"
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?
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.
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).
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 '
the whole coinselector in bitcoin core appears to have been written with a strong assumption that an address isn't used more than once. :(
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
do you know if src/qt/res/bitcoin-qt-res.rc can use PRODUCT_NAME?
jonasschnelli: re isolating "Bitcoin Core" to fewer places.. there's 8 instances in the .ui files; I could move those to the equivalent .cpp, but it would look not-so-nice in Designer; thoughts?
let's rename to Nucleul Bitcoin in all languages. it sounds nicer.
nucleul sounded after a reasonable Bitcoin wallet name...:-)
jonasschnelli_: hehe in Dutch it's called "Bitcoin Kern"
Maybe my lol was inappropriate (I thought he is using a different wallet (Nucleul Bitcoin versiunea v0.11.0 (32-bit)), but looks like core. Could be that the user really face an issue/bug.
AFAIK bitcoin core is the only wallet thats ever supported priority on the send side, and it's never even optimized for using priority wisely.
gmaxwell, using this argument, this calls for a lot of NEW users to bitcoin to call for "restart" of the network...
Luke-Jr, either fees become a significant portion of the total block reward and miners acting in their own self interest ignore priority, or we have massively misjudged the economic rational for mining and bitcoin will fail
believe it or not, most miners *do* care to some degree about Bitcoin's success