1 2017-02-06 02:31:28	0|ossifrage|FYI, the usage for 'dumpwallet' really should say that the filename is an output file not an input file. I thought it was an 'input file' and you can imagine what happened...
  2 2017-02-06 02:39:32	0|sipa|where is it called 'input file' ?
  3 2017-02-06 02:55:20	0|bitcoin-git|[13bitcoin] 15gmaxwell opened pull request #9693: Prevent integer overflow in ReadVarInt. (06master...06varint_maxsize) 02https://github.com/bitcoin/bitcoin/pull/9693
  4 2017-02-06 03:02:07	0|gmaxwell|morcos: did you see https://github.com/bitcoin/bitcoin/issues/9645  ? sounds like a good point... and probably easy to do.
  5 2017-02-06 04:36:31	0|jl2012|MarcoFalke_: it works. Thanks
  6 2017-02-06 07:46:04	0|wumpus|luke-jr: how would you propose to do that? allow, say, either an argument amount=1.23 or an argument amount_int=123000000?
  7 2017-02-06 07:48:21	0|luke-jr|wumpus: I would propose that whenever named params are used, amounts are always satoshis.
  8 2017-02-06 07:48:23	0|sipa|i suggest we at some point introduce a global amount_unit, which modifies the units all amounts are accepted and shown in
  9 2017-02-06 07:48:43	0|sipa|which can be done at any time, in a backward compatible way
 10 2017-02-06 07:48:45	0|wumpus|sipa: I had a pull open for that at some point
 11 2017-02-06 07:48:50	0|sipa|ah!
 12 2017-02-06 07:49:28	0|luke-jr|there should be no existing code using named params right now, so there's no need to be "compatible" with fractional numbers
 13 2017-02-06 07:49:31	0|wumpus|there were even four options - satoshis as number, satoshis as string, BTC as number, BTC as string
 14 2017-02-06 07:49:58	0|wumpus|it could be set using a configuration option, everything using AMountFrom* and *ToAmount would use this
 15 2017-02-06 07:50:32	0|sipa|wumpus: well we already support both strings and numbers everywhere, no?
 16 2017-02-06 07:50:40	0|wumpus|hardly any interest, though, so eventually rotted and closed. I think despite being a favourite discussion topic for developers, very people are actually concerned about these units on the RPC interface
 17 2017-02-06 07:51:08	0|sipa|agre
 18 2017-02-06 07:51:11	0|wumpus|arguably interoperability is best by just allowing one representation
 19 2017-02-06 07:51:17	0|wumpus|and yes, strings are allowed as inputs
 20 2017-02-06 07:51:28	0|wumpus|it would apply to both inputs and outputs though
 21 2017-02-06 07:51:48	0|wumpus|in any case I think this is abit of a non-issue
 22 2017-02-06 07:52:18	0|luke-jr|so NACK for 0.14? :x
 23 2017-02-06 07:52:30	0|wumpus|heh :)
 24 2017-02-06 07:52:52	0|sipa|i think it's way too late to change that for 0.14, and given that we already support strings as amount... i'm not sure it's necessary at all
 25 2017-02-06 07:53:10	0|wumpus|agree
 26 2017-02-06 07:53:28	0|luke-jr|sipa: only reason to push for it in 0.14 is to avoid having to ever support BTC amounts in named-params mode for backwards compat
 27 2017-02-06 07:53:43	0|wumpus|let's please not conflate named-param with any other interface change
 28 2017-02-06 07:53:47	0|sipa|luke-jr: well we'll always have to support it in non-named-params anyway
 29 2017-02-06 07:54:09	0|luke-jr|wumpus: ok, then my idea is controversial and not worth spending more time on
 30 2017-02-06 07:54:37	0|wumpus|I mean imagine it from the user point of view, you decide to change your RPC binding to use named arguments, and suddenly you have to use different units!
 31 2017-02-06 07:54:47	0|luke-jr|seems logical to me ☺
 32 2017-02-06 08:19:01	0|bitcoin-git|[13bitcoin] 15theuni opened pull request #9695: net: fix a few races. Credit @TheBlueMatt (06master...06net-atomic) 02https://github.com/bitcoin/bitcoin/pull/9695
 33 2017-02-06 08:21:34	0|cfields|blah, i really need to stop using "race" and "concurrent access" interchangeably
 34 2017-02-06 08:22:39	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/923dc447eaa8...fc67cd22f83f
 35 2017-02-06 08:22:40	0|bitcoin-git|13bitcoin/06master 14ac719c9 15Gregory Maxwell: Init ECC context for test_bitcoin_fuzzy....
 36 2017-02-06 08:22:41	0|bitcoin-git|13bitcoin/06master 14fc67cd2 15Wladimir J. van der Laan: Merge #9691: Init ECC context for test_bitcoin_fuzzy....
 37 2017-02-06 08:23:00	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9691: Init ECC context for test_bitcoin_fuzzy. (06master...06fuzzy_initecc) 02https://github.com/bitcoin/bitcoin/pull/9691
 38 2017-02-06 11:49:22	0|bitcoin-git|13bitcoin/06master 144ec057d 15Russell Yanofsky: [wallet] Set correct metadata on bumpfee wallet transactions...
 39 2017-02-06 11:49:22	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/fc67cd22f83f...8d6447ecf79c
 40 2017-02-06 11:49:23	0|bitcoin-git|13bitcoin/06master 148d6447e 15Wladimir J. van der Laan: Merge #9673: Set correct metadata on bumpfee wallet transactions...
 41 2017-02-06 11:49:41	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9673: Set correct metadata on bumpfee wallet transactions (06master...06pr/bumpfee-meta) 02https://github.com/bitcoin/bitcoin/pull/9673
 42 2017-02-06 13:20:33	0|bitcoin-git|13bitcoin/06master 145f62e3e 15practicalswift: Fix typos
 43 2017-02-06 13:20:33	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/8d6447ecf79c...986ba005eda6
 44 2017-02-06 13:20:34	0|bitcoin-git|13bitcoin/06master 14986ba00 15Wladimir J. van der Laan: Merge #9651: Fix typos...
 45 2017-02-06 13:20:52	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9651: Fix typos (06master...06typos) 02https://github.com/bitcoin/bitcoin/pull/9651
 46 2017-02-06 13:35:18	0|bitcoin-git|[13bitcoin] 15laanwj pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/986ba005eda6...09e0c28f8566
 47 2017-02-06 13:35:19	0|bitcoin-git|13bitcoin/06master 14d45955f 15Jorge Timón: Net: CConnman: Make some methods const
 48 2017-02-06 13:35:19	0|bitcoin-git|13bitcoin/06master 14fc7f2ff 15Jorge Timón: Net: Make CNetMsgMaker more const
 49 2017-02-06 13:35:20	0|bitcoin-git|13bitcoin/06master 140729102 15Jorge Timón: Net: pass interruptMsgProc as const where possible
 50 2017-02-06 13:35:33	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9659: Net: Turn some methods and params/variables const (06master...060.14-net-more-const) 02https://github.com/bitcoin/bitcoin/pull/9659
 51 2017-02-06 13:51:48	0|bitcoin-git|[13bitcoin] 15laanwj pushed 6 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/09e0c28f8566...40f7e27d25ff
 52 2017-02-06 13:51:49	0|bitcoin-git|13bitcoin/06master 147ea0ad5 15Matt Corallo: Fail in DecodeHexTx if there is extra data at the end
 53 2017-02-06 13:51:49	0|bitcoin-git|13bitcoin/06master 14922bea9 15Matt Corallo: Better handle invalid parameters to signrawtransaction...
 54 2017-02-06 13:51:50	0|bitcoin-git|13bitcoin/06master 14691710a 15Matt Corallo: [qa] Test that decoderawtransaction throws with extra data appended
 55 2017-02-06 13:52:04	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9650: Better handle invalid parameters to signrawtransaction (06master...062017-01-better-signraw) 02https://github.com/bitcoin/bitcoin/pull/9650
 56 2017-02-06 13:58:26	0|bitcoin-git|13bitcoin/06master 1439c77b0 15Russell Yanofsky: Add documentation for CWalletTx::fFromMe member.
 57 2017-02-06 13:58:26	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/40f7e27d25ff...870cd2b58aba
 58 2017-02-06 13:58:27	0|bitcoin-git|13bitcoin/06master 14870cd2b 15Wladimir J. van der Laan: Merge #9378: [trivial] Add documentation for CWalletTx::fFromMe member....
 59 2017-02-06 13:58:36	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9378: [trivial] Add documentation for CWalletTx::fFromMe member. (06master...06pr/fromme-doc) 02https://github.com/bitcoin/bitcoin/pull/9378
 60 2017-02-06 14:17:28	0|achow101|how likely is the rc1 tag going to happen today?
 61 2017-02-06 14:17:55	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #9696: [trivial] Fix recently introduced typos in comments (06master...06fix-recently-introduced-typos) 02https://github.com/bitcoin/bitcoin/pull/9696
 62 2017-02-06 14:33:38	0|bitcoin-git|[13bitcoin] 15jonasschnelli opened pull request #9697: [Qt] simple fee bumper with user verification (06master...062017/02/qt_bumpfee) 02https://github.com/bitcoin/bitcoin/pull/9697
 63 2017-02-06 15:14:48	0|bitcoin-git|13bitcoin/06master 14d63ff62 15Patrick Strateman: Make nWalletDBUpdated atomic to avoid a potential race.
 64 2017-02-06 15:14:48	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/870cd2b58aba...02464da5e4aa
 65 2017-02-06 15:14:49	0|bitcoin-git|13bitcoin/06master 1402464da 15Wladimir J. van der Laan: Merge #9227: Make nWalletDBUpdated atomic to avoid a potential race....
 66 2017-02-06 15:14:58	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9227: Make nWalletDBUpdated atomic to avoid a potential race. (06master...062016-11-26-nwalletdbupdated-race) 02https://github.com/bitcoin/bitcoin/pull/9227
 67 2017-02-06 19:06:20	0|BlueMatt|hum...if you get a "Work queue depth exceeded" error from RPC bitcoin-cli will give you a "couldn't parse reply from server"
 68 2017-02-06 19:58:24	0|bitcoin-git|[13bitcoin] 15theuni opened pull request #9698: net: fix socket close race (06master...06fix-socket-disconnect2) 02https://github.com/bitcoin/bitcoin/pull/9698
 69 2017-02-06 20:25:59	0|bitcoin-git|[13bitcoin] 15droark opened pull request #9699: Remove contrib/debian/patches subdirectory (06master...06removedebpatches) 02https://github.com/bitcoin/bitcoin/pull/9699
 70 2017-02-06 20:42:46	0|arubi|what's "insecure" about the old binaries on bitcoin.org?  should fine to run on regtest right?
 71 2017-02-06 20:43:14	0|arubi|er, meaning : https://bitcoin.org/bin/insecure/
 72 2017-02-06 20:43:33	0|luke-jr|arubi: likely different on a case-by-case basis
 73 2017-02-06 20:43:58	0|luke-jr|https://bitcoin.org/bin/insecure/README.txt
 74 2017-02-06 20:44:18	0|arubi|ah I see, failed at rtfm.  thanks
 75 2017-02-06 20:45:03	0|arubi|yea that's what I figured, just the known issues throught the releases, cheers
 76 2017-02-06 21:00:45	0|bitcoin-git|[13bitcoin] 15sdaftuar opened pull request #9700: Cache segwit signature hash components inside CTransaction to optimize validation performance (06master...062017-02-segwit-hash-cache-2) 02https://github.com/bitcoin/bitcoin/pull/9700
 77 2017-02-06 21:03:49	0|arubi|I guess the 0.8.6 binary doesn't have -regtest (other nodes refusing connection and the switch is missing from -help), 0e4b31755 has it and says 0.8.2 beta in the readme, I guess it didn't become part of the binary until later :)
 78 2017-02-06 21:04:50	0|luke-jr|arubi: regtest isn't a network.. you shouldn't ever try to connect it to other nodes (besides in a test environment)
 79 2017-02-06 21:05:32	0|arubi|luke-jr, oh I'm well aware.  these are all local, running a local regtest network
 80 2017-02-06 21:05:53	0|luke-jr|I wouldn't be surprised if it was incompatible with different versions
 81 2017-02-06 21:06:26	0|arubi|0.9.5+ worked, thought about trying the older versions
 82 2017-02-06 21:07:36	0|arubi|oh I guess only 0.10.0+ worked, I didn't try 0.9.5 yet.
 83 2017-02-06 21:14:24	0|arubi|'connect() to 127.3.0.2:18444 failed after select(): Connection refused' :(, wonder if it's just issues in my config..
 84 2017-02-06 21:14:44	0|arubi|oh lol
 85 2017-02-06 21:15:06	0|arubi|yea, gotta star the daemons first..
 86 2017-02-06 21:18:00	0|arubi|anyway, for completeness, I can get 0.9.0 to connect, but not 0.8.6.  I guess I'm missing some milestone where regtest was actually released in 0.9.0 :)
 87 2017-02-06 21:33:06	0|BlueMatt|sipa: yo
 88 2017-02-06 21:33:27	0|sipa|yo
 89 2017-02-06 21:33:36	0|BlueMatt|sipa: i think you're missing my point - the precalculations will be done in net/wallet, not that they need the data
 90 2017-02-06 21:33:45	0|sipa|that feels wrong
 91 2017-02-06 21:33:54	0|BlueMatt|because you want the data available during signing (it doesnt matter much, but its nice), and also in orphans
 92 2017-02-06 21:34:08	0|sipa|why do you need signature data for orphans?
 93 2017-02-06 21:34:13	0|sipa|you can't verify it
 94 2017-02-06 21:34:15	0|BlueMatt|so doing it transparently in the tx object is the cleanest way by far
 95 2017-02-06 21:34:21	0|sipa|i strongly disagree
 96 2017-02-06 21:34:24	0|BlueMatt|so that its available when you reconstruct the block
 97 2017-02-06 21:34:29	0|sipa|this is 1 step forward and a dozen backward
 98 2017-02-06 21:34:52	0|BlueMatt|the whole point of the patch is to have the data precalculated when the txn are floating around from various sources (orphan, mempool, recent rejects, etc)
 99 2017-02-06 21:34:58	0|BlueMatt|so that when they go into the block its great
100 2017-02-06 21:35:19	0|BlueMatt|and its a serious win
101 2017-02-06 21:35:45	0|sipa|there should be a way to keep it restricted to validation...
102 2017-02-06 21:35:54	0|sipa|we're not putting wallet specific data in CTransaction either
103 2017-02-06 21:35:58	0|BlueMatt|if you insist on CTransaction being a "dumb storage" object, then sdaftuar had a previous version that made CTransactionRef a "transaction and extra data" reference object
104 2017-02-06 21:36:16	0|BlueMatt|its transaction-specific data...you need the sighashes when signing, too
105 2017-02-06 21:36:22	0|BlueMatt|so the wallet does care about this data, technically
106 2017-02-06 21:36:41	0|BlueMatt|and I would heasitate to call any hashes of the tx "validation-specific"
107 2017-02-06 21:36:41	0|sipa|i mean we're not putting vfSpent or hashBlock in CTransaction
108 2017-02-06 21:36:53	0|BlueMatt|sure, because those require otuside data
109 2017-02-06 21:36:55	0|sipa|they're part of the consensus rules, and up
110 2017-02-06 21:36:58	0|BlueMatt|this is all data which is entirely self-contained
111 2017-02-06 21:36:59	0|sipa|not part of serialization
112 2017-02-06 21:37:11	0|BlueMatt|nor is hash, would you like to not cache that?
113 2017-02-06 21:38:04	0|sipa|well i don't like the hash there either
114 2017-02-06 21:38:13	0|BlueMatt|where the hell else would you put it?
115 2017-02-06 21:38:26	0|BlueMatt|its the "in-memory serialization"
116 2017-02-06 21:38:32	0|BlueMatt|sure its duplicative, but its hella useful
117 2017-02-06 21:38:36	0|BlueMatt|and so is witness hashes
118 2017-02-06 21:39:09	0|BlueMatt|at some point this is, by far, the cleanest way to get a massive win, so I really disagree that it shouldn't be done
119 2017-02-06 21:39:48	0|BlueMatt|if you insist on a "data storage class" we can do a wrapper around CTransaction with extra caches (like sdaftuar's original with CTransactionRef becomming a class)
120 2017-02-06 21:39:56	0|sipa|i understand it may be needed now for a performance improvement
121 2017-02-06 21:40:00	0|BlueMatt|this would also pull shared_ptr out of primitives/
122 2017-02-06 21:40:08	0|sipa|but you seem to be arguing that it's overall an improvement and should be the goal
123 2017-02-06 21:40:15	0|BlueMatt|I am, indeed
124 2017-02-06 21:40:34	0|BlueMatt|............
125 2017-02-06 21:48:31	0|gmaxwell|Will http://www.codesynthesis.com/~boris/blog/2012/04/25/shared-ptr-aliasing-constructor/ let us have a wrapping object without an additional allocation overhead?
126 2017-02-06 21:50:14	0|BlueMatt|doesnt seem like it?
127 2017-02-06 21:50:23	0|cfields|gmaxwell: heh, i've looked at those a bunch for this purpose, but never seemed to come up with anything helpful
128 2017-02-06 21:50:39	0|cfields|it sure _seems_ like it could help, though
129 2017-02-06 21:52:00	0|BlueMatt|gmaxwell: if we were to turn CTransactionRef (or equivalent) into a primitive+cache object, we dont need to take extra overhead, though, I believe
130 2017-02-06 21:52:39	0|BlueMatt|gmaxwell: it can be class CTransactionAndCachedValidationInfo { CTransaction tx; ValidationInfoCache cache; }; typedef CTransactionRef std::shared_ptr<CTransactionAndCachedValidationInfo>;
131 2017-02-06 21:53:06	0|BlueMatt|it gets yucky when you ask what a block contains, though
132 2017-02-06 21:53:21	0|BlueMatt|you end up with like templating CBlock to let it work with either type of transaction object.....
133 2017-02-06 21:55:49	0|BlueMatt|(which is arguably not a layer violation and really doesnt blow up too much, since you pretty much always want the additional validation info in it - only exception is reading block from disk for sending to peer, which could be done via some other function)
134 2017-02-06 21:56:23	0|BlueMatt|but is so damn ugly that I'd heasitate to ever recommend it
135 2017-02-06 23:56:10	0|bitcoin-git|[13bitcoin] 15ryanofsky opened pull request #9701: Make bumpfee tests less fragile (06master...06pr/bumpfee-fragile) 02https://github.com/bitcoin/bitcoin/pull/9701