1 2016-07-27 00:01:14	0|luke-jr|https://github.com/bitcoin/libblkmaker/pull/6 review requested
  2 2016-07-27 00:37:05	0|phantomcircuit|wumpus: what else more do i need to do on https://github.com/bitcoin/bitcoin/pull/8152 ?
  3 2016-07-27 00:37:19	0|phantomcircuit|jonasschnelli: same question ^
  4 2016-07-27 08:34:20	0|jonasschnelli|phantomcircuit: Looks good. I really want to run some tests. I'll do that soon. But 8152 is definitively useful and will be merged soon.
  5 2016-07-27 08:53:08	0|jonasschnelli|wumpus: I think https://github.com/bitcoin/bitcoin/pull/8152 is ready for merge (into master)
  6 2016-07-27 08:55:13	0|wumpus|thanks, taking a look
  7 2016-07-27 09:01:00	0|wumpus|I'm still not entirely convinced that it won't reduce performance by causing more flushes to disk
  8 2016-07-27 09:01:50	0|wumpus|e.g. the reason for passing those CWalletDB in the first place (it wasn't always that way) was to prevent extraneous flushes, as sipa says in that pull
  9 2016-07-27 09:03:18	0|wumpus|but if anyone can convince me that that problem has been handled in another way I'm ok with merging it
 10 2016-07-27 09:03:30	0|wumpus|(or even better, benchmarks)
 11 2016-07-27 09:04:26	0|wumpus|jonasschnelli: re: 8407, I think the second commit makes the code unncesarily complex; I think we can already handle all upgrade scenarios without it
 12 2016-07-27 09:04:57	0|jonasschnelli|wumpus: IMO 8152 is only a refactoring to avoid having CWalletDB access in rpc code.
 13 2016-07-27 09:05:13	0|jonasschnelli|wumpus: re 8407, I agree. I will remove the second commit asap
 14 2016-07-27 09:06:30	0|wumpus|yes avoiding CWalletDB access in the RPC code is great; but that could also have been accomplished by adding a wrapper method in CWallet
 15 2016-07-27 09:07:00	0|wumpus|that passes through the wtx to AddToWallet and opens the walletdb
 16 2016-07-27 09:07:13	0|wumpus|what I'm worried about is the internal uses of AddToWallet that do pass their own walletdb
 17 2016-07-27 09:08:16	0|wumpus|eh - do those exist at all?
 18 2016-07-27 09:08:25	0|jonasschnelli|wumpus: I have checked the internal AddToWallet uses. And it seems like they all open CWalletDB shortly before resulting in the ~same behavior.
 19 2016-07-27 09:09:03	0|jonasschnelli|I think the change form (external calls) pwalletMain->AddToWallet(wtx, false, &walletdb); to  pwalletMain->AddToWallet(wtx); is good.
 20 2016-07-27 09:09:20	0|jonasschnelli|It hides CWalletDB behind CWallet
 21 2016-07-27 09:09:36	0|wumpus|hmm I agree
 22 2016-07-27 09:09:37	0|jonasschnelli|(for callers using AddToWallet)
 23 2016-07-27 09:10:02	0|wumpus|LOL @ line 910
 24 2016-07-27 09:10:03	0|jonasschnelli|But as I said. I think its a refactoring PR
 25 2016-07-27 09:10:35	0|jonasschnelli|wumpus: you mean the return false at L910
 26 2016-07-27 09:10:45	0|wumpus|of wallet.cpp - that line could be deleted, no one is using that walletdb :-)
 27 2016-07-27 09:10:58	0|wumpus|CWalletDB walletdb(strWalletFile, "r+", false);    return AddToWallet(wtx);
 28 2016-07-27 09:11:27	0|wumpus|I'm looking at the merged version, line numbers may be off
 29 2016-07-27 09:11:42	0|jonasschnelli|Ah. Yes. That should be removed I guess.
 30 2016-07-27 09:12:28	0|wumpus|so what changes here is the parameters under which walletdb is opened
 31 2016-07-27 09:12:55	0|wumpus|for that AddWallet it used to be the ("r+", false), but now it wil open the walletdb inside AddToWallet with default parameters
 32 2016-07-27 09:14:12	0|wumpus|ok, commented on the pull
 33 2016-07-27 11:26:34	0|jonasschnelli|I think this one is ready for merge https://github.com/bitcoin/bitcoin/pull/8206
 34 2016-07-27 11:26:46	0|jonasschnelli|Its a required 0.13 backport and relatively risk free
 35 2016-07-27 12:41:14	0|wumpus|jonasschnelli: yes I was planning to test it, will do so
 36 2016-07-27 12:41:25	0|jonasschnelli|Thanks
 37 2016-07-27 13:02:13	0|wumpus|jonasschnelli: a small nit: cVjNjjiDXCsTZKVP3VzjH3PPdNdeS7t51RXJ6rt99GgnzaTFtrxz 2016-07-27T13:00:33Z label= # addr=mfZRKaG9dfW5xEqUWiJFFFohe8XXoW297N hdkeypath: m/0'/0'/0'
 38 2016-07-27 13:02:28	0|wumpus|let's format it hdkeypath= instead of hdkeypath:
 39 2016-07-27 13:02:33	0|wumpus|that's more consistent
 40 2016-07-27 13:02:47	0|jonasschnelli|ah. right. Let me change that directly
 41 2016-07-27 13:03:23	0|wumpus|thanks
 42 2016-07-27 13:03:43	0|wumpus|apart from that it works, tested with a non-HD and a HD wallet
 43 2016-07-27 13:04:00	0|jonasschnelli|wumpus: what do you think about changing "oldhdmaster" to "inactivehdmaster"?
 44 2016-07-27 13:04:15	0|jonasschnelli|oldhdmaster sound not ideal
 45 2016-07-27 13:04:28	0|wumpus|yes seems more on-point
 46 2016-07-27 13:04:39	0|jonasschnelli|okay. Will change that as well
 47 2016-07-27 13:05:09	0|wumpus|it not so much matters whether old or new, just that it's not used at the moment
 48 2016-07-27 13:05:50	0|wumpus|or maybe a more heretical idea: number the master keys, and store what master key was used with the key metadata
 49 2016-07-27 13:06:09	0|wumpus|maybe for 0.14
 50 2016-07-27 13:07:08	0|jonasschnelli|wumpus: yes. Though about that. But would add nother "long" string to each line
 51 2016-07-27 13:07:21	0|jonasschnelli|or we could add an index to each master key (for simplification)
 52 2016-07-27 13:08:06	0|wumpus|yes indeed my idea was an index/handle, not the full master key id
 53 2016-07-27 13:08:54	0|wumpus|that would indeed be ugly, and would take up significant extra space in the metadata
 54 2016-07-27 13:09:01	0|jonasschnelli|Yes. This would make sense for 0.14 I guess.
 55 2016-07-27 13:09:37	0|jonasschnelli|https://github.com/bitcoin/bitcoin/pull/8206 is featureish and I think we only backport it to 0.13 because of possible complains because of lack of exporting the xpriv
 56 2016-07-27 13:10:16	0|wumpus|yes I agree we don't want to do this for 0.13
 57 2016-07-27 13:10:20	0|wumpus|it was just a wild idea
 58 2016-07-27 13:10:39	0|wumpus|for 8206 let's just fix the output format and merge it
 59 2016-07-27 13:12:03	0|jonasschnelli|wumpus: I think 8206 is ready now
 60 2016-07-27 13:13:09	0|wumpus|re-testing
 61 2016-07-27 13:18:38	0|wumpus|jonasschnelli: cRv7Mpp7w5vtf4y8joSPs6kwGZAuKfPa76GzhGS7Vecq3ss4t5Fh 2016-07-27T13:00:33Z reserve=1 # addr=mpEFHw5CXTi69tHcZm62x9DJgbQewP731j hdkeypath= m/0'/0'/1'
 62 2016-07-27 13:18:46	0|wumpus|I think that's a space too much after = :)
 63 2016-07-27 13:19:10	0|jonasschnelli|Damit... :) force pushed.
 64 2016-07-27 13:19:32	0|jonasschnelli|ah. Forgot "git add".
 65 2016-07-27 13:19:40	0|jonasschnelli|wumpus: now pushed
 66 2016-07-27 13:26:13	0|GitHub44|13bitcoin/06master 1477c912d 15Jonas Schnelli: [Wallet] add HD xpriv to dumpwallet
 67 2016-07-27 13:26:13	0|GitHub44|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/beadffae6d65...4d4970fe530a
 68 2016-07-27 13:26:14	0|GitHub44|13bitcoin/06master 144d4970f 15Wladimir J. van der Laan: Merge #8206: [Wallet] Add HD xpriv to dumpwallet...
 69 2016-07-27 13:26:18	0|GitHub179|[13bitcoin] 15laanwj closed pull request #8206: [Wallet] Add HD xpriv to dumpwallet (06master...062016/06/hd_info) 02https://github.com/bitcoin/bitcoin/pull/8206
 70 2016-07-27 13:27:17	0|jonasschnelli|wumpus: does 77c912d apply cleanly to 0.13 (should)? Just tell me if you want me to open a PR against 0.13
 71 2016-07-27 13:27:36	0|wumpus|going to try
 72 2016-07-27 13:29:26	0|wumpus|seems to just apply
 73 2016-07-27 13:41:25	0|GitHub42|13bitcoin/060.13 1418b8ee1 15Jonas Schnelli: [Wallet] add HD xpriv to dumpwallet...
 74 2016-07-27 13:41:25	0|GitHub42|[13bitcoin] 15laanwj pushed 1 new commit to 060.13: 02https://github.com/bitcoin/bitcoin/commit/18b8ee1cd1b2c95faac53e49b9023200679f2bb1
 75 2016-07-27 13:52:53	0|wumpus|8389 needs rebase
 76 2016-07-27 14:03:25	0|jonasschnelli|rebased
 77 2016-07-27 14:26:23	0|wumpus|jonasschnelli: did you see my remark here: https://github.com/bitcoin/bitcoin/pull/8407/files#r72257114  ... I'm not sure what settings.value(strSettingsVersionKey) returns in the case !settings.contains(strSettingsVersionKey), but if it's garbage or raises an exception this may be problematic
 78 2016-07-27 14:31:12	0|jonasschnelli|wumpus: yes saw it. But I thought the second expression in the if gets not executed if the first one (.contains()) fails. It's an OR.
 79 2016-07-27 14:31:51	0|wumpus|yes that is true, but look inside the {} there is another settings.value(strSettingsVersionKey)
 80 2016-07-27 14:32:03	0|wumpus|if (settings.value(strSettingsVersionKey) < 130000 &&  ...
 81 2016-07-27 14:32:23	0|jonasschnelli|Ah. Right!
 82 2016-07-27 14:32:45	0|jonasschnelli|That needs to be fixed. Will do soon (afk/phone typing).
 83 2016-07-27 14:32:56	0|wumpus|yes, no hurry
 84 2016-07-27 16:33:53	0|GitHub191|13bitcoin/060.13 140179a39 15Wladimir J. van der Laan: qt: periodic translations update
 85 2016-07-27 16:33:53	0|GitHub191|[13bitcoin] 15laanwj pushed 1 new commit to 060.13: 02https://github.com/bitcoin/bitcoin/commit/0179a39f9da1fa417a592e7bf3ebbb1390a292b9
 86 2016-07-27 18:03:36	0|goatpig|hi
 87 2016-07-27 18:04:10	0|goatpig|you don't need the mask and flag when creating a tx with only segwit outputs, do you?
 88 2016-07-27 18:04:27	0|goatpig|as in, no segwit inputs redeeming, only creating segwit outputs
 89 2016-07-27 18:04:32	0|goatpig|non nested
 90 2016-07-27 18:13:25	0|luke-jr|goatpig: that is my understanding, correct
 91 2016-07-27 18:14:01	0|luke-jr|furthermore, I think you can even include such outputs in non-segwit blocks. albeit, they would be vulnerable to easy theft until segwit activates.
 92 2016-07-27 18:14:18	0|luke-jr|(but it's possible to mine non-segwit blocks even after segwit activates, so not entirely useless)
 93 2016-07-27 18:15:10	0|goatpig|in this case they would just behave as anyone can spend wouldn't they? at least until miners start enforcing segwit rules
 94 2016-07-27 18:17:14	0|luke-jr|right
 95 2016-07-27 18:17:40	0|goatpig|so the proper guideline would be to add mask and flag when creating non nested segwit outputs, regardless of inputs?
 96 2016-07-27 18:18:08	0|luke-jr|even after segwit activates, libblkmaker will produce non-segwit blocks if there are no witness-as-input transactions being mined
 97 2016-07-27 18:18:16	0|gmaxwell|Well they're non-standard currently.
 98 2016-07-27 18:18:35	0|luke-jr|goatpig: I don't understand your question there
 99 2016-07-27 18:18:46	0|goatpig|im thinking for after segwit is activated, I don't intent to allow ppl to create SW tx with Armory until a few weeks after that happens on the mainnet
100 2016-07-27 18:18:59	0|luke-jr|IIRC, it's invalid to have dummy/flag if there's no witness data for inputs
101 2016-07-27 18:19:08	0|goatpig|luke-jr: oic
102 2016-07-27 18:19:20	0|luke-jr|(I could be wrong on that, but IIRC)
103 2016-07-27 18:19:42	0|goatpig|wouldn't that mean that you can't mix regular and sw outputs in a same tx?
104 2016-07-27 18:19:59	0|luke-jr|goatpig: no, you can have dummy/flag so long as at least one input needs witness data
105 2016-07-27 18:20:06	0|goatpig|ok
106 2016-07-27 18:20:33	0|goatpig|aight that sums it for me
107 2016-07-27 18:20:35	0|goatpig|thanks for the help
108 2016-07-27 19:46:11	0|jtimon|mhmm, there's a bitcoinconsensus_SCRIPT_FLAGS_VERIFY_WITNESS but not a bitcoinconsensus_SCRIPT_VERIFY_CHECKSEQUENCEVERIFY in script/bitcoinconsensus.h...
109 2016-07-27 19:49:39	0|sipa|jtimon: good point, we should fix that
110 2016-07-27 19:50:18	0|jtimon|I'll PR it, just wanted to confirm first
111 2016-07-27 19:50:23	0|jtimon|sipa: thanks
112 2016-07-27 19:51:18	0|jtimon|actually found out while adapting my consensus branch to ScriptFlagsFromConsensus()as discussed (WIP)
113 2016-07-27 21:13:39	0|GitHub48|[13bitcoin] 15jtimon opened pull request #8412: libconsensus: Expose a flag for BIP112 (06master...060.13-consensus-bip112-flag) 02https://github.com/bitcoin/bitcoin/pull/8412
114 2016-07-27 21:14:09	0|jtimon|does this little thing break rc1?
115 2016-07-27 21:49:36	0|GitHub132|[13bitcoin] 15jtimon opened pull request #8413: Trivial: pass Consensus::Params& instead of CChainParams& in ContextualCheckBlock (06master...060.13-consensus-last-params) 02https://github.com/bitcoin/bitcoin/pull/8413
116 2016-07-27 22:18:01	0|jtimon|btcdrak: quick question https://github.com/bitcoin/bitcoin/pull/8412#issuecomment-235738474
117 2016-07-27 22:26:57	0|jtimon|never mind, updated without bip112 at the end
118 2016-07-27 23:32:27	0|GitHub43|[13bitcoin] 15kazcw opened pull request #8414: prepend license statement to indirectmap.h (06master...06indirectmap-license) 02https://github.com/bitcoin/bitcoin/pull/8414