1 2017-07-28 01:13:24	0|bitcoin-git|[13bitcoin] 15gmaxwell opened pull request #10945: Update defaultAssumeValid according to release-process.md. (06master...06201707-update-assumevalid) 02https://github.com/bitcoin/bitcoin/pull/10945
  2 2017-07-28 05:19:03	0|bitcoin-git|[13bitcoin] 15sipa opened pull request #10946: Add chainwork to getchaintxstats (06master...0620170727_chainworkstats) 02https://github.com/bitcoin/bitcoin/pull/10946
  3 2017-07-28 05:33:22	0|gmaxwell|sipa: should I add updating ChainTxData to the PR I have for the assumevalid?
  4 2017-07-28 05:50:25	0|sipa|gmaxwell: ?
  5 2017-07-28 05:51:02	0|gmaxwell|sipa: I have a PR open to update the assumevalid, I could update chainTxData too, I was reminded by your above PR.
  6 2017-07-28 05:55:54	0|wumpus|profall: it's really useful for giving whole UTXOs away
  7 2017-07-28 05:56:34	0|wumpus|(or alternatively, sending them to some other wallet of yourself, but the idea is to not have to add anything extra for fee, resulting in change)
  8 2017-07-28 05:57:05	0|wumpus|this used to be a process of bisection
  9 2017-07-28 05:59:11	0|sipa|gmaxwell: ah, i see!
 10 2017-07-28 05:59:23	0|sipa|i just wrote thst PR to verify your nMinimumChainWork
 11 2017-07-28 05:59:56	0|gmaxwell|sipa: yes, I responded to that PR to point out that the info is already in getblockchaininfo, the release process docs tell you how to verify it. :)
 12 2017-07-28 06:07:41	0|wumpus|"The fee rate (in %s/kB) used to discard change (to fee) if it would be dust at this fee rate (default: %s) Note: We will always discard up to the dust relay fee and a discard fee above that is limited by the longest target fee estimate"
 13 2017-07-28 06:07:44	0|wumpus|this confuses translators
 14 2017-07-28 06:08:28	0|wumpus|- "the dust relay fee" -- this sounds like a fee applied to relaying dust; is it?
 15 2017-07-28 06:08:38	0|wumpus|- "a discard fee" -- this sounds like a fee applied when discarding something, which is probably isn't. Does it relate to the fee rate which seems to be the main topic of this string?
 16 2017-07-28 06:08:49	0|wumpus|- "discard change (to fee)" -- perhaps the explanation in the parentheses could be more precise. Does this suggest that the change is added to the fee in case it is otherwise considered dust? Then perhaps the parentheses may say something like "(by adding change to the fee instead)"?
 17 2017-07-28 06:09:02	0|wumpus|- "longest target fee estimate" -- which of the other words does "longest" relate to here? Could this be rewritten as "longest estimete of the target fee", or perhaps "fee estimate of the longest target", or something else?
 18 2017-07-28 06:10:13	0|wumpus|is this a user-servicable option at all? if not, might I propose moving it to debug-help wholesale and not translating it?
 19 2017-07-28 06:15:29	0|wumpus|it uses too many internal technical terms that appear nowhere else, which indicates that someone that doesn't know internal wallet logic has no business setting it
 20 2017-07-28 06:16:37	0|sipa|longest refers to long term estimate, i believe
 21 2017-07-28 06:16:55	0|sipa|i would agree with making it an expert/debug option
 22 2017-07-28 06:19:55	0|gmaxwell|I don't think the target thing should really be a user servisable option.
 23 2017-07-28 06:20:02	0|gmaxwell|The discard threshold is.
 24 2017-07-28 06:20:52	0|wumpus|this is about 'discardfee=<amt>'
 25 2017-07-28 06:20:57	0|wumpus|well if so, it needs better documentation
 26 2017-07-28 06:22:26	0|wumpus|this is from a person that has been translating bitcoin strings to Danish for a long time, I think it's a good indication that if he doesn't understand any of it, no other non-dev will
 27 2017-07-28 06:22:43	0|gmaxwell|Right!
 28 2017-07-28 06:25:02	0|wumpus|this again makes me doubt whether it makes sense to translate option helps at all. It's a bit like translating obscure error messages - having a variant of the technical terms in every language doesn't make it easier to look for
 29 2017-07-28 06:25:23	0|wumpus|especially if the translators don't understand it and just do a literal translation
 30 2017-07-28 09:27:04	0|bitcoin-git|[13bitcoin] 15NicolasDorier opened pull request #10947: [Wallet] Bare segwit scriptPubKey are not considered change by the wallet (06master...06importaddresssegwit) 02https://github.com/bitcoin/bitcoin/pull/10947
 31 2017-07-28 10:28:01	0|promag|wumpus: I think #10885 is ready
 32 2017-07-28 10:28:03	0|gribble|https://github.com/bitcoin/bitcoin/issues/10885 | Reject invalid wallets by promag · Pull Request #10885 · bitcoin/bitcoin · GitHub
 33 2017-07-28 10:39:59	0|wumpus|promag: thanks
 34 2017-07-28 10:43:40	0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #10948: p2p: Hardcoded seeds update pre-0.15 branch (06master...062017_07_seeds_update) 02https://github.com/bitcoin/bitcoin/pull/10948
 35 2017-07-28 10:51:55	0|sipa|wumpus: we have a number of obvious but invasive scripted refactors... what is your opinion on what a good time for those is?
 36 2017-07-28 10:52:46	0|sipa|i was thinking (assuming they're acceptable, of course), that right before branching may be advisable, so as to not hurt backportability of fixes
 37 2017-07-28 10:53:45	0|sipa|that does go against the idea of not having invasive changes after freeze
 38 2017-07-28 10:54:14	0|wumpus|sipa: well as long as they're not features, straightforward, and low-risk, it could be ok
 39 2017-07-28 10:55:03	0|gmaxwell|My view is that getting those kinds of safe refactors in before branching is good because it helps backports.
 40 2017-07-28 10:55:35	0|bitcoin-git|[13bitcoin] 15laanwj pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/0b11a0784875...70888a39c43a
 41 2017-07-28 10:55:36	0|bitcoin-git|13bitcoin/06master 143ef77a0 15João Barbosa: Reject duplicate wallet filenames
 42 2017-07-28 10:55:36	0|bitcoin-git|13bitcoin/06master 14a6da027 15João Barbosa: Reject invalid wallet files
 43 2017-07-28 10:55:37	0|bitcoin-git|13bitcoin/06master 14d84e78e 15John Newbery: [wallet] Specify wallet name in wallet loading errors
 44 2017-07-28 10:56:10	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10885: Reject invalid wallets (06master...062017-07-prevent-duplicate-wallets) 02https://github.com/bitcoin/bitcoin/pull/10885
 45 2017-07-28 10:56:42	0|wumpus|well it seems to be quite quiet this time before branch, so it seems we could get around to that
 46 2017-07-28 10:56:51	0|wumpus|which ones is this about?
 47 2017-07-28 11:17:22	0|sipa|wumpus: #10483 at elast
 48 2017-07-28 11:17:24	0|gribble|https://github.com/bitcoin/bitcoin/issues/10483 | scripted-diff: Use the C++11 keyword nullptr to denote the pointer literal instead of the macro NULL by practicalswift · Pull Request #10483 · bitcoin/bitcoin · GitHub
 49 2017-07-28 11:18:10	0|sipa|#10607
 50 2017-07-28 11:18:12	0|gribble|https://github.com/bitcoin/bitcoin/issues/10607 | scripted-diff: stop using the gArgs wrappers by benma · Pull Request #10607 · bitcoin/bitcoin · GitHub
 51 2017-07-28 11:19:06	0|sipa|i assumed there were more, but they're not scripted
 52 2017-07-28 11:26:27	0|wumpus|tagged them for 0.15
 53 2017-07-28 13:24:18	0|morcos|wumpus: re: -discardfee help
 54 2017-07-28 13:24:32	0|morcos|I agree it is a slightly involved concept
 55 2017-07-28 13:25:00	0|morcos|I originally had a shorter message but ryanofsky asked me to include the information about its interaction with dust and estimates
 56 2017-07-28 13:25:32	0|morcos|It's almost like that more technical information should only be included if you have showDebug
 57 2017-07-28 13:26:25	0|wumpus|yes, the problem is not so much that there is extra information, but that it refers to all kinds of terms that are unknown to users
 58 2017-07-28 13:26:27	0|morcos|I kind of agree with gmaxwell that this is kind of a user serviceable option.  It's your tolerance for throwing money away to fee rather than creating a small output
 59 2017-07-28 13:26:46	0|wumpus|maybe that's a better help message :)
 60 2017-07-28 13:27:03	0|wumpus|those are terms everyone can relate to :-)
 61 2017-07-28 13:27:43	0|morcos|The only issue is where the correct place is to document how it interacts with these other things... but perhaps the code is sufficient
 62 2017-07-28 13:27:49	0|wumpus|but yeah the question is when someone would set it
 63 2017-07-28 13:28:10	0|wumpus|heh it's almost as if having only option documentation isn't enough anymore
 64 2017-07-28 13:28:41	0|wumpus|not that we have any kind of other documentation where this would be a good place for :/
 65 2017-07-28 13:28:43	0|morcos|I'm guessing they would set it if they wonder why they are occasionally paying a higher fee and they are really trying to avoid that
 66 2017-07-28 13:28:56	0|morcos|You know.. maybe we should just move it to be a debug option
 67 2017-07-28 13:29:33	0|morcos|Well I'm wiling to change it whichever way we think is best
 68 2017-07-28 13:30:41	0|wumpus|as I said, another option would be to never translate command line option help at all, I don't think descriptions like this will be improved by translation in most cases
 69 2017-07-28 13:31:14	0|morcos|Yes or could we just not have them translate the "Note:" part
 70 2017-07-28 13:31:29	0|wumpus|translation would be ideally used for things like UI messages that use normal english, and a set of defined common terms for the application
 71 2017-07-28 13:31:48	0|wumpus|there's not really any win in translating concepts we've made up ourselves
 72 2017-07-28 13:32:30	0|wumpus|yeah
 73 2017-07-28 13:33:02	0|morcos|The fee rate (in %s/kB) that indicates your tolerance used for discarding change by adding it to the fee. (default: %s) Note: An output is discarded if it is dust at this rate, but we will always discard up to the dust relay fee and a discard fee above that is limited by the longest target fee estimate
 74 2017-07-28 13:33:07	0|wumpus|what is funny, in practice the command-line options are only translated when you call --help through bitcoin-qt, not when using bitcoind
 75 2017-07-28 13:33:18	0|wumpus|(the latter doesn't contain the translation data)
 76 2017-07-28 13:33:29	0|morcos|s/used//
 77 2017-07-28 13:35:03	0|morcos|1.) Change to above   2) Change to above and delete note.   A) Move to Debug option
 78 2017-07-28 13:35:05	0|wumpus|morcos: better!
 79 2017-07-28 13:35:13	0|morcos|I'm fine with 1,2,1A,2A or nothing
 80 2017-07-28 13:38:12	0|wumpus|I'm fine with all as well, but 1 seems best
 81 2017-07-28 13:38:41	0|morcos|will do
 82 2017-07-28 13:44:39	0|sipa|morcos: it is user servicable? things will may go badly though if you set if sufficiently different from the rest of the network, no?
 83 2017-07-28 13:47:47	0|morcos|sipa: how do you mean?
 84 2017-07-28 13:48:15	0|morcos|no, it is only used to increase what would be already thrown away by the dustrelayfee
 85 2017-07-28 13:48:44	0|morcos|which is also an option but i agree a non-user-servicable one that should not be changed
 86 2017-07-28 13:50:41	0|morcos|actually not sure if we are there yet, but ideally once we have this option, then it should be fine to lower the dustrelayfee to accomplish greg's goal of no longer having that concept, as long as your discardfee doesn't go below the OLD dustrelayfee.
 87 2017-07-28 13:51:02	0|morcos|but there are some slight other issues there such as with fee estimation
 88 2017-07-28 13:55:47	0|bitcoin-git|[13bitcoin] 15morcos opened pull request #10949: Clarify help message for -discardfee (06master...06betterhelp) 02https://github.com/bitcoin/bitcoin/pull/10949
 89 2017-07-28 15:15:03	0|Lightsword|for #10301 should I leave getentropy via sys/random.h as OSX only or try and generalize it?
 90 2017-07-28 15:15:05	0|gribble|https://github.com/bitcoin/bitcoin/issues/10301 | Check if sys/random.h is required for getentropy. by jameshilliard · Pull Request #10301 · bitcoin/bitcoin · GitHub
 91 2017-07-28 15:38:41	0|jonasschnelli|Lightsword: I guess it makes sense on OSX 10.12(+) ..
 92 2017-07-28 15:42:57	0|jonasschnelli|Lightsword: Do you expect other operating systems providing getentropy() via sys/random.h?
 93 2017-07-28 15:43:49	0|Lightsword|jonasschnelli, well looks like it’s there on solaris but I don’t really have a way to test against that, OSX also uses the weak import fork backwards compatibility
 94 2017-07-28 15:45:03	0|jonasschnelli|Lightsword: By "generalize" you mean removing the  && defined(MAC_OSX)?
 95 2017-07-28 15:45:08	0|Lightsword|yeah
 96 2017-07-28 15:45:36	0|jonasschnelli|I don't see a reason why not do to that.
 97 2017-07-28 15:46:24	0|Lightsword|well there was a glibc issue right?
 98 2017-07-28 15:46:27	0|jonasschnelli|But maybe ask cfields what he things
 99 2017-07-28 15:46:30	0|jonasschnelli|thinks
100 2017-07-28 16:13:06	0|wumpus|Lightsword: I'd make it macosx specific
101 2017-07-28 16:13:29	0|wumpus|we should vet OSes where using getentropy is safe one by one
102 2017-07-28 16:13:31	0|Lightsword|wumpus, yeah I went that way since there was an openbsd specific version
103 2017-07-28 16:13:35	0|wumpus|right.
104 2017-07-28 16:18:00	0|wumpus|I initially made it too generalized, which caused a few issues (with linux, for example) in the first place
105 2017-07-28 16:18:33	0|wumpus|not serious issues with randomness, luckily, but build problems
106 2017-07-28 21:44:14	0|kanzure|sendtoaddress doesn't seem to do any chaining off of other sendtoaddress-constructed unconfirmed outputs. and getbalance doesn't have a flag to ignore amounts stuck in unconfirmed sendtoaddress-generated outputs. i think fundrawtransaction is my only option, is that right?
107 2017-07-28 21:47:34	0|kanzure|i guess i could use listunspent minconf=1 and check if the result is empty and/or take the sum of the amounts if any.
108 2017-07-28 21:50:04	0|kanzure|anyway, the getbalance RPC docstring could at least mention that it is a highly promiscuous definition of available, and the sendtoaddress docstring could mention the lack of chaining..
109 2017-07-28 22:00:43	0|sipa|kanzure: well getbalance follows the mempool's rules for availability... and long chains of dependent transactions don't get into the mempool
110 2017-07-28 22:01:46	0|sipa|getbalance will aim to avoid spending low-confirmation count outputs, and avoid long-ubconfirmed-chain outputs if possible
111 2017-07-28 22:03:09	0|kanzure|my use case was very simple, i had mined some initial blocks, needed to spend them somewhere, was spending a bunch of tiny amounts, exhausted available utxos; my test was checking getbalance and mining a block if the balance was below some threshold. but the balance is reported as very high despite having no sendtoaddress-spendable coins, oops.
112 2017-07-28 22:49:23	0|kanzure|also, how do i debug "insufficient fee" in regtest mode? the transaction is 3528 bytes paying 30 sat/byte (so 105840 sat).