1 2017-06-20 06:02:01	0|jonasschnelli|travis cancels jobs: " This job ran on our Trusty, sudo: required environment which will be updated on Wednesday, June 21st. Please add group: edge to your .travis.yml file to try the new images and check our blog for more details about this update."
  2 2017-06-20 06:03:06	0|jonasschnelli|Seems only here: https://github.com/bitcoin/bitcoin/pull/10633
  3 2017-06-20 06:31:40	0|luke-jr|has anyone tested that? will edge just work? :x
  4 2017-06-20 07:47:22	0|MarcoFalke|jup, tested it a few days ago. No issues
  5 2017-06-20 07:50:21	0|MarcoFalke|btw jonasschnelli. Do you think would be hard to get machine readable urls for your gitian builds?
  6 2017-06-20 07:50:42	0|MarcoFalke|Maybe /nightly/2017/06/19/ or /nightly/latest/
  7 2017-06-20 07:50:53	0|jonasschnelli|Yes. I can do that...
  8 2017-06-20 07:51:08	0|jonasschnelli|I already did that for PRs: https://bitcoin.jonasschnelli.ch/build/PR/10628
  9 2017-06-20 07:51:17	0|MarcoFalke|Awesome, thx.
 10 2017-06-20 07:51:20	0|jonasschnelli|(redirects to the newest build id of that PR)
 11 2017-06-20 08:02:47	0|bitcoin-git|[13bitcoin] 15dimitris-t closed pull request #10634: Fixed typos in optionsdialog.ui (06master...06patch-2) 02https://github.com/bitcoin/bitcoin/pull/10634
 12 2017-06-20 08:03:24	0|bitcoin-git|[13bitcoin] 15dimitris-t closed pull request #10635: Fixed typo in rpcconsole.cpp (06master...06patch-3) 02https://github.com/bitcoin/bitcoin/pull/10635
 13 2017-06-20 08:12:30	0|jonasschnelli|MarcoFalke: okay. Works: https://bitcoin.jonasschnelli.ch/build/nightly/latest
 14 2017-06-20 08:12:36	0|jonasschnelli|https://bitcoin.jonasschnelli.ch/build/nightly/2017/06/17
 15 2017-06-20 11:57:44	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #10636: [qa] util: Check return code after closing bitcoind proc (06master...06Mf1706-qaTraceback) 02https://github.com/bitcoin/bitcoin/pull/10636
 16 2017-06-20 16:59:58	0|sturles|If I add a watchonly address to Bitcoin Core, and it receives a transaction output, and add the private key for the same address later.  Will the output become spendable without a rescan?
 17 2017-06-20 17:30:40	0|ryanofsky_|sturles, it should unless there is a bug
 18 2017-06-20 18:02:41	0|sturles|ryanofsky_: Cool!  I'll try to use it with pull request #9728 in a semi-hot wallet.  Just add private keys as required to fill up.  Avoiding a bitcoin transaction to refill the hot wallet.
 19 2017-06-20 18:02:43	0|gribble|https://github.com/bitcoin/bitcoin/issues/9728 | Can create Watch Only HD wallet with -hdwatchonly by NicolasDorier · Pull Request #9728 · bitcoin/bitcoin · GitHub
 20 2017-06-20 18:09:44	0|bitcoin-git|[13bitcoin] 15achow101 opened pull request #10637: Coin Selection with Murch's algorithm (06master...06bnb-coin-select) 02https://github.com/bitcoin/bitcoin/pull/10637
 21 2017-06-20 18:26:19	0|instagibbs|sturles, if you're doing p2sh you may need to pass the redeemscript as well
 22 2017-06-20 18:38:42	0|sipa_|cfields: any idea how it is possible that passing libbitcoin_util before libbitcoin_wallet on the linking cmdline works?
 23 2017-06-20 18:38:49	0|instagibbs|achow101, so your PR doesn't touch the looping or target behavior, just coin selection itself?
 24 2017-06-20 18:38:54	0|achow101|yes
 25 2017-06-20 18:39:24	0|sipa_|cfields: wallet.cpp uses FastRandomContext's constructor, which is defined in libbitcoin_util...
 26 2017-06-20 18:39:37	0|achow101|instagibbs: It needs to use effective values and access to fee rate so I only borrowed a few parts of your effective value PR for those
 27 2017-06-20 18:40:44	0|cfields|sipa_: they're all tangled up. iirc last time i checked, there was no ordering that wasn't circular.
 28 2017-06-20 18:41:00	0|cfields|i worked out how it was working at that point, let me refresh my memory
 29 2017-06-20 18:42:46	0|sipa_|but we're not passing any grouping to the linker, so it shouldn't be able to resolve circular dependencies?
 30 2017-06-20 18:43:01	0|sipa_|i can swap util and wallet
 31 2017-06-20 18:43:06	0|sipa_|but there are other pairs that i can't swap
 32 2017-06-20 18:45:39	0|instagibbs|achow101, trying to decide how dangerous that is on its own. If it results in no change, but too high of a fee due to the looping, we'll dump all that value into fee :(
 33 2017-06-20 18:45:54	0|instagibbs|knapsack specializes in exact matches, so red flags are going up for me
 34 2017-06-20 18:46:56	0|sipa_|instagibbs: the idea is that the extra fee will not be more than what it would cost to create + spend change
 35 2017-06-20 18:47:10	0|instagibbs|sipa_, hold on let me get the issue im speaking of
 36 2017-06-20 18:47:19	0|sipa_|ok
 37 2017-06-20 18:47:25	0|instagibbs|https://github.com/bitcoin/bitcoin/issues/10247
 38 2017-06-20 18:47:39	0|instagibbs|basically what happens is if it loops it keeps accumulating what it thinks is "enough absolute fee"
 39 2017-06-20 18:47:56	0|instagibbs|so on subsequent attempts the number of inputs may shrink dramatically, but still results in large fee
 40 2017-06-20 18:48:06	0|instagibbs|if there's a change output, we handle it gracefully now by bumping the change
 41 2017-06-20 18:48:11	0|instagibbs|no change, we still dump
 42 2017-06-20 18:48:20	0|instagibbs|I attempted to address this in https://github.com/bitcoin/bitcoin/pull/10333
 43 2017-06-20 18:48:45	0|sipa_|instagibbs: i see
 44 2017-06-20 18:49:06	0|achow101|interesting. how would we know if that's a problem with the different coin selection?
 45 2017-06-20 18:49:19	0|sipa_|that sounds like an existing issue that we need to fix, and perhaps the knapsack coin selection could make it worse
 46 2017-06-20 18:49:21	0|instagibbs|well it only rears it's head on "exact matches"
 47 2017-06-20 18:49:25	0|instagibbs|yep that ^
 48 2017-06-20 18:50:00	0|instagibbs|imo #10333 is pretty easy to review, and is 0.15 possible if people start reviewing
 49 2017-06-20 18:50:01	0|gribble|https://github.com/bitcoin/bitcoin/issues/10333 | [wallet] fee fixes: always create change, adjust value, and p… by instagibbs · Pull Request #10333 · bitcoin/bitcoin · GitHub
 50 2017-06-20 18:51:24	0|achow101|instagibbs: so since the new coin selection is supposed to get "exact matches" more frequently, we could be running into the high fees problem?
 51 2017-06-20 18:52:13	0|instagibbs|if it loops a few times, failing to "get enough", then when it does, it's more likely to get an exact match, then vastly overpay fees. This tends to happen on wallets with lots of utxos
 52 2017-06-20 18:52:57	0|instagibbs|the PR you got the commits from should also fix this issue more holistically, but larger review surface
 53 2017-06-20 18:56:06	0|cfields|sipa_: just finished what I was working on. looking and refreshing now.
 54 2017-06-20 18:57:13	0|achow101|instagibbs: I thought about taking the entire rewritten loop from the effective value PR but I wasn't sure if that would break anything or use stuff that you changed that I didn't grab
 55 2017-06-20 19:05:13	0|cfields|sipa_: ah, i believe it works because of the libs already added. eg. FastRandomContext was already emitted by util for server
 56 2017-06-20 19:06:38	0|cfields|(I recently discussed a strategy for nuking wallet's deps on server with jonasschnelli, i believe he's begun PRing some of the necessary changes)
 57 2017-06-20 19:14:13	0|jonasschnelli|cfields: But that PR is a very first beginning... it would require much more work
 58 2017-06-20 19:15:31	0|cfields|jonasschnelli: sure. I just wanted to point out that there's at least _some_ desire to work out the dependency mess :)
 59 2017-06-20 19:15:48	0|jonasschnelli|Yes. Lets clean this up
 60 2017-06-20 19:19:13	0|cfields|jonasschnelli: what's the PR you've already opened? I need to make sure to review/ack
 61 2017-06-20 19:19:18	0|gmaxwell|instagibbs: at least based on the design I understand, when achows' patch does something there will be no looping because by design it picked a solution that had enough fee.
 62 2017-06-20 19:19:41	0|jonasschnelli|cfields: #10517
 63 2017-06-20 19:19:43	0|gribble|https://github.com/bitcoin/bitcoin/issues/10517 | Factor out CCoinsView based AreInputsStandard/IsWitnessStandard by jonasschnelli · Pull Request #10517 · bitcoin/bitcoin · GitHub
 64 2017-06-20 19:19:49	0|jonasschnelli|(needs rebase)
 65 2017-06-20 19:19:50	0|cfields|jonasschnelli: thanks
 66 2017-06-20 19:20:55	0|gmaxwell|instagibbs: it takes the original target feerate as an argument and does all its calculations with effective fees, and only allows overpayment to the extent that costs equal or less than the future change spend that it avoided.
 67 2017-06-20 19:21:29	0|instagibbs|gmaxwell, ok let me re-read, because that's what my PR is supposed to be doing, heh
 68 2017-06-20 19:22:14	0|gmaxwell|instagibbs: no, your PR does it on everything; not just in the exact match case. Which I raised the dust inflation concern above. (which it seems no one is interested in doing anything about...)
 69 2017-06-20 19:22:56	0|gmaxwell|This doesn't have the dust inflation concern, since it only has an effect when there is no change (thus no increase in the number of outputs).
 70 2017-06-20 19:25:04	0|sipa_|cfields: FastRandomContext iirc is only in libbitcoin_util... how is wallet able to use it? wallet is passed later on the cmdline
 71 2017-06-20 19:25:22	0|gmaxwell|To reiterate: the concern I have with your effective rate change is that it will make wallets be unlikely to select low effective rate coins and never select negative effective rate coins. But will still create change, which seems almost certian to cause an increase in UTXO set bloat.  And this effect is mostly tangential from the problem you're trying to solve, which is related to non-convexity
 72 2017-06-20 19:25:28	0|gmaxwell|of the fee search.
 73 2017-06-20 19:26:06	0|instagibbs|gmaxwell, I removed that a long time ago
 74 2017-06-20 19:26:40	0|instagibbs|anyways, let met do a fuller review, I'm getting myself turned around
 75 2017-06-20 19:27:33	0|cfields|sipa_: it's used by net_processing in server, which marks it as undefined. Then util resolves it. Then it's already resolved for wallet.
 76 2017-06-20 19:28:25	0|sipa_|cfields: ugh
 77 2017-06-20 19:28:28	0|sipa_|ok
 78 2017-06-20 19:29:09	0|gmaxwell|instagibbs: ah, I had lost track of the fact that you had PRed a change that addressed the overpayment without doing the effective rate thing.
 79 2017-06-20 19:29:26	0|achow101|I'm confused :(
 80 2017-06-20 19:30:00	0|instagibbs|achow101, wallet code makes people scared and afraid, don't worry
 81 2017-06-20 19:30:22	0|gmaxwell|instagibbs: this new PR creates dust change. :(
 82 2017-06-20 19:31:09	0|instagibbs|gmaxwell, it tries "relatively hard" to avoid making something less than MIN_FINAL_CHANGE
 83 2017-06-20 19:31:21	0|instagibbs|unfortunately without something smarter we just have to pick something and shoot for it
 84 2017-06-20 19:31:31	0|instagibbs|open to ideas though
 85 2017-06-20 19:32:46	0|achow101|gmaxwell: which PR creates dust change? Mine?
 86 2017-06-20 19:32:57	0|gmaxwell|achow101: instagibbs
 87 2017-06-20 19:32:59	0|instagibbs|#10333
 88 2017-06-20 19:33:00	0|gribble|https://github.com/bitcoin/bitcoin/issues/10333 | [wallet] fee fixes: always create change, adjust value, and p… by instagibbs · Pull Request #10333 · bitcoin/bitcoin · GitHub
 89 2017-06-20 19:33:05	0|achow101|ah, ok
 90 2017-06-20 19:34:27	0|instagibbs|achow101, https://github.com/bitcoin/bitcoin/pull/10333/files#diff-b2bb174788c7409b671c46ccc86034bdR2630
 91 2017-06-20 19:34:29	0|gmaxwell|It could use murch's hurestic to cut that down further. (Murch's hurestic is that you can throw away change if it's less that FeeRate*(34+4+1+34+74)  (cost to create and spend that change output).
 92 2017-06-20 19:34:56	0|instagibbs|so there's the "I will enver make an output this small" level which could be that ^
 93 2017-06-20 19:34:58	0|gmaxwell|(with adjustments for different script types)
 94 2017-06-20 19:35:04	0|instagibbs|then there's also the "I'm willing to try again"
 95 2017-06-20 19:35:12	0|instagibbs|and get something bigger or an exact match
 96 2017-06-20 19:35:30	0|instagibbs|toss vs rety, I mean
 97 2017-06-20 19:36:13	0|gmaxwell|instagibbs: the patch achow submitted is fairly close to guarenteed to give an 'exact' (uses that hurestic) match if one is possible.
 98 2017-06-20 19:37:56	0|instagibbs|so if we simply fail to get an exact match we should likely grab some buffer more we want as change, whatever that is
 99 2017-06-20 19:43:59	0|gmaxwell|achow101: what instagibbs is talking about at this start of this conversation is related to how fees are handled by selecting coins, finding we need to pay a larger fee than we selected, then going back with a bigger target.  What can happen now is that on one iteration you select a zillion inputs, decide you need a lot of fee, then go back, but this time your higher targets means you select onl
100 2017-06-20 19:44:05	0|gmaxwell|y a couple inputs, but you got close enough to your fee-inflated-target that you do not include a change output... and then you overpay fee.
101 2017-06-20 19:45:10	0|gmaxwell|achow101: and I think what you are intending to accomplish is completely orthorgonal with that defect. (perhaps the implementation isn't-- but the idea is)
102 2017-06-20 19:45:36	0|achow101|gmaxwell: oh, ok.
103 2017-06-20 19:46:48	0|achow101|gmaxwell: as the implementation is right now, I don't think it will exit the loop if a BnB algo passes though
104 2017-06-20 19:47:41	0|achow101|also, something else to consider is if the BnB algo fails on one loop so it falls back to the original algo, but then on the next pass (with the fee regtarget thing) the BnB algo passes. I'm not sure what would happen in that case
105 2017-06-20 19:49:56	0|instagibbs|lots of fee, I think
106 2017-06-20 19:51:27	0|gmaxwell|achow101: thats the "perhaps the implemetation isn't-- but the idea is" part.  Probably the BnB should just be skipped after the first iteration.
107 2017-06-20 20:04:44	0|gmaxwell|instagibbs: I think your 10333 is more attractive in light of achow's PR, assuming they were correctly combined.  Since his PR will do a pretty good job of finding a changless solution, if there is one, I think it's fine to make the rest of the behavior just assume there will be change.   Though perhaps I gave achow bad advice on the integration.  I suggested just replacing out the selectcoins p
108 2017-06-20 20:04:50	0|gmaxwell|art in order to avoid having to handle coincontrol and fee-from-amount.
109 2017-06-20 20:05:56	0|gmaxwell|combined naievely it will be pretty bad.
110 2017-06-20 20:43:00	0|cfields|jonasschnelli: ping. still around?
111 2017-06-20 20:44:55	0|gaf_|is any reason to worry about segwitx2 has about 77~ or who cares about it, because this donest affecting anything?
112 2017-06-20 20:52:45	0|instagibbs|gmaxwell, if we limit the BnB stuff to the first step, this removes any need for 10333 to correct any additional bad behavior
113 2017-06-20 21:02:51	0|ProfMac|If not here, where can I discuss this?
114 2017-06-20 21:02:54	0|ProfMac|I have a set of directories, sandbox-1493974463, sandbox-1494226733, and the like.  I have set up a git server, and put the earliest sandbox under git control following, e.g., https://git-scm.com/book/en/v2/Git-on-the-Server-Setting-Up-the-Server  Now I want to move to the next sandbox.  I assume I need to do git {init, remote add,  ...} but I am a little wobbly about "pull"  The goal is to add the changes in the 2nd sandb
115 2017-06-20 21:26:18	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #10638: [rpc] Clarify pblock assumption via an assertion (06master...06nnonce) 02https://github.com/bitcoin/bitcoin/pull/10638
116 2017-06-20 21:29:46	0|gmaxwell|instagibbs: hm? perhaps I don't get your comment.  Are you saying 10333 is not needed post achow making his pr run only on the first step?
117 2017-06-20 21:39:16	0|instagibbs|gmaxwell, I don't think it's needed for the first BnB run, but just as needed otherwise as before
118 2017-06-20 21:50:12	0|gmaxwell|instagibbs: okay agreed.
119 2017-06-20 21:51:15	0|gmaxwell|instagibbs: question I have is with all those changes, should the exact match attempt just be taken out of the loop?  it will mean duplicating recipent pays fes logic.
120 2017-06-20 21:59:19	0|gmaxwell|instagibbs: I was also thinking of another strategy for your loop logic that I think may be better and more clear:  target=amount; 1. Assume change. Attempt selection. if it fails is there a saved solution? if so return that.  Compute fees? if not increase target to current fees, goto 1.  Can change be elimiated (<murch hurestic) if so do so and return solution. If not, is the change above the M
121 2017-06-20 21:59:25	0|gmaxwell|IN_CHANGE? if so then stop and take that one. If not, save the solution, and target=max(amount+fee+min_change, target*1.01) and goto 1.
122 2017-06-20 22:00:24	0|gmaxwell|so basically it guarentees the target goes up with every iteration, and only gives up and uses the dusty solution if its already tried raising the target beyond the wallet's capacity.
123 2017-06-20 22:01:37	0|gmaxwell|it doesn't make any real attempt to avoid change, since I assume achow101's first step handles that.. though if it happens to find itself with an acceptably changeless solution then it will accept it.
124 2017-06-20 22:17:03	0|instagibbs|"should the exact match attempt just be taken out of the loop" had this exact thought. It's something to look at imo.
125 2017-06-20 22:19:17	0|instagibbs|what would a "saved solution" be in this case?
126 2017-06-20 22:19:50	0|gmaxwell|saved solution would just be the transaction, one where the solution was viable but had non-eliminatable change under the min_change target.
127 2017-06-20 22:20:32	0|gmaxwell|so we keep looking (with ever higher targets) after it, hoping to get something that passes, but if we don't we can return the dusty one.
128 2017-06-20 22:22:53	0|instagibbs|ah, so if < dust, accept, < min_change, save and try again higher, loop
129 2017-06-20 22:23:36	0|gmaxwell|yea, so long as the loop increases enough each iteration it'll terminate in acceptable time.
130 2017-06-20 22:24:52	0|gmaxwell|so, e.g. when the wallet doesn't have enough in it to meet min_change you'll go for that the next iteration, find your selection fails, then take the slightly dusty one from the last go.
131 2017-06-20 23:17:08	0|bitcoin-git|13bitcoin/06master 144265bf3 15practicalswift: Remove unreachable or otherwise redundant code
132 2017-06-20 23:17:08	0|bitcoin-git|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/c38f540298f0...d636f3943d39
133 2017-06-20 23:17:09	0|bitcoin-git|13bitcoin/06master 14d636f39 15Pieter Wuille: Merge #10536: Remove unreachable or otherwise redundant code...
134 2017-06-20 23:17:34	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #10536: Remove unreachable or otherwise redundant code (06master...06unreachable) 02https://github.com/bitcoin/bitcoin/pull/10536