1 2018-01-15 00:22:11	0|CubicEarths|sipa: you here?
  2 2018-01-15 01:54:33	0|bitcoin-git|[13bitcoin] 15NicolasDorier closed pull request #10947: [Wallet] Bare segwit scriptPubKey should not considered change by the wallet (06master...06importaddresssegwit) 02https://github.com/bitcoin/bitcoin/pull/10947
  3 2018-01-15 02:08:40	0|bitcoin-git|[13bitcoin] 15jeffrade opened pull request #12187: [Docs] Updating benchmarkmarking.md with an updated sample output (06master...06benchmark_output) 02https://github.com/bitcoin/bitcoin/pull/12187
  4 2018-01-15 06:33:50	0|CubicEarths|I know there are more sophisticated UTXO plans in the works, but as a quick-fix, why not have a soft-fork where for every 100th block to be valid the miner would have to include two hashes, one of all the blocks up a recent point, and another hash of the UTXO set as of that same recent point?
  5 2018-01-15 06:35:39	0|gmaxwell|CubicEarths: to accomplish what goal?
  6 2018-01-15 06:35:51	0|gmaxwell|If you want spv security use a blinking SPV client.
  7 2018-01-15 06:36:18	0|CubicEarths|blinking?
  8 2018-01-15 06:37:09	0|CubicEarths|oh, you are not using that word in a technical sense.
  9 2018-01-15 06:37:22	0|gmaxwell|hah, yes.
 10 2018-01-15 06:41:08	0|luke-jr|CubicEarths: how do you know the UTXO hash is legit? (hint: you'd have to verify all the prior blocks..)
 11 2018-01-15 06:43:41	0|CubicEarths|The idea would be that since it would be a consensus rule, the miner and all others building on top that block of it would verify the the utxo set hashed to that value
 12 2018-01-15 06:43:57	0|gmaxwell|If you want to blindly trust miners, you can do that-- thats what SPV does.
 13 2018-01-15 06:44:02	0|CubicEarths|as well as all full nodes
 14 2018-01-15 06:44:41	0|gmaxwell|it's much more efficient than what it sounds like you're imagining, requires no new consensus rules, and doesn't create normative behavior that requires nodes hash gigabytes of data to validate a block.
 15 2018-01-15 06:48:08	0|gmaxwell|which is why I opened with the question of what goal you hoped to accomplish.
 16 2018-01-15 06:49:20	0|CubicEarths|Blind trust in this context wouldn't be a good thing. It seems like there is middle ground between that and 'everybody checks everything all the time'.
 17 2018-01-15 06:50:55	0|gmaxwell|Where you trust miners to only produce valid blocks because someone else is checking is the SPV model, it's somewhat disproved in practice thanks to spy mining, but if you want to make that assumption you already can, super duper efficiently.
 18 2018-01-15 06:52:23	0|CubicEarths|I though SPV mining was only an issue that could go back a few blocks at most?
 19 2018-01-15 06:52:58	0|gmaxwell|what? no.
 20 2018-01-15 06:53:28	0|gmaxwell|it means miners produce and extend chanins without validating them which means that spv wallets will see false confirmations.
 21 2018-01-15 06:53:59	0|CubicEarths|yes, but only a few false confirmations. They wouldn't go 20 blocks deep
 22 2018-01-15 06:54:14	0|CubicEarths|or not 100 at least :)
 23 2018-01-15 06:54:54	0|gmaxwell|no one is going to wait 100 blocks on confirmations unfortunately. I know of only one commercial party that was doing it, and they abandoned it.
 24 2018-01-15 06:55:19	0|gmaxwell|But there is also no limit to the reorg depth that could be created by spymining, just depends on how much participation there is.
 25 2018-01-15 06:56:16	0|CubicEarths|Right. If all miners were mining garbage, then the block chain would be just be junk
 26 2018-01-15 06:57:33	0|gmaxwell|at least the sitaution has improved in the last few months and miners no longer think they can force invalid blocks onto the network merely by mining them. :)
 27 2018-01-15 06:58:00	0|gmaxwell|For a while I worried that there would be some spymining incident with an invalid block, and we'd have miners saying "screw you, we're not going to reorg out our blocks".
 28 2018-01-15 06:58:39	0|CubicEarths|yeah, I could see that
 29 2018-01-15 06:58:48	0|gmaxwell|then there would be some long outage while the rest of the network forked off those miners.
 30 2018-01-15 06:59:06	0|gmaxwell|but I think that the outcome is now pretty clear.
 31 2018-01-15 07:02:04	0|CubicEarths|So, I guess the utxo hash idea is a way of network helping nodes to get online. The network enforces rules that make it easier for new nodes to join, and in turn enforce those rules themselves. It makes it easier to have a rotating pool of nodes who validate the miners.
 32 2018-01-15 07:09:07	0|luke-jr|CubicEarths: if only miners are verifying blocks, why *wouldn't* they do 100 and beyond?
 33 2018-01-15 07:13:32	0|CubicEarths|luke-jr: It wouldn't only be miners. I really don't understand the thinking behind why everyone needs to run a node for Bitcoin to be secure. It seems like a diminishing returns situation. If 1 out 100 people in the work run a node, I just can't really envision what would could wrong that would be made better by 99 out of 100 running nodes
 34 2018-01-15 07:14:12	0|luke-jr|CubicEarths: if 1% of the economy runs a node, then 99% of the economy moves on with an invalid chain and becomes dependent on the outcome of that chain
 35 2018-01-15 07:14:31	0|luke-jr|putting a huge economic pressure on the 1% rejecting that chain, to change their mind and accept it
 36 2018-01-15 07:15:01	0|luke-jr|that 1% can no longer pay the other 99% which won't accept their coins as valid
 37 2018-01-15 07:16:15	0|luke-jr|the 99% won't suddenly decide to lose out on their income because 1% says the chain is invalid
 38 2018-01-15 07:19:47	0|CubicEarths|I envision more like the 99% would back their clients with local full nodes that they trust, and they should even be able to tap into 10 or 100 full nodes that they trust (because they trust the operators), and query them simultaneously to look for signs of disagreement. Could what you are proposing work in the situation I described?
 39 2018-01-15 07:24:57	0|luke-jr|I'm not proposing anything?
 40 2018-01-15 07:26:48	0|CubicEarths|the risk you proposed
 41 2018-01-15 07:28:01	0|luke-jr|if they trust node operators, they're fine until those node operators are compromised
 42 2018-01-15 07:28:17	0|luke-jr|assuming a secure connection to them
 43 2018-01-15 07:32:33	0|CubicEarths|well if the ability to connect to an arbitrary number of nodes and cross check their answers exits, it seems safe to assume that they wouldn't all be compromised at once
 44 2018-01-15 07:33:17	0|CubicEarths|at least it hardly seems riskier than assuming your own node would be compromised at the same time (if you had one)
 45 2018-01-15 07:36:28	0|luke-jr|CubicEarths: you can't interchange trusted nodes and arbitrary nodes..
 46 2018-01-15 07:36:59	0|CubicEarths|I meant an arbitrary number of trusted nodes
 47 2018-01-15 07:39:28	0|luke-jr|but now you're getting back to a fiat trust model
 48 2018-01-15 07:40:14	0|CubicEarths|•
 49 2018-01-15 07:40:41	0|CubicEarths|Maybe I should sell my BTC :)
 50 2018-01-15 07:43:51	0|CubicEarths|I dunno, it seems different if: 1) There is PoW 2) Anyone can mine 3) Anyone can run a node to validate 4) I decide no to run a full node but instead connect to 100 nodes run by people and organizations that I trust
 51 2018-01-15 07:45:25	0|CubicEarths|It seems like quite a small difference between running a full node and doing some advanced SPV in that context
 52 2018-01-15 07:46:06	0|CubicEarths|at least in terms of reorgs and being double spent
 53 2018-01-15 08:58:02	0|bitcoin-git|13bitcoin/06master 148e617e3 15Suhas Daftuar: Remove unused mempool index
 54 2018-01-15 08:58:02	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/45cf8a03cb57...9501dc27b336
 55 2018-01-15 08:58:03	0|bitcoin-git|13bitcoin/06master 149501dc2 15Wladimir J. van der Laan: Merge #12127: Remove unused mempool index...
 56 2018-01-15 08:58:58	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12127: Remove unused mempool index (06master...062018-01-remove-unused-index) 02https://github.com/bitcoin/bitcoin/pull/12127
 57 2018-01-15 09:09:57	0|sipa|i wonder if this would speed up our unit tests: https://idea.popcount.org/2013-07-19-how-to-sleep-a-million-years/
 58 2018-01-15 09:10:08	0|sipa|(and if not, it's still very cool)
 59 2018-01-15 09:12:30	0|wumpus|if I understand it correctly, we do the same using mock times, but it's certainly an interesting approach
 60 2018-01-15 09:13:44	0|sipa|s/unit/functional/
 61 2018-01-15 09:14:31	0|sipa|the advantage is that it works across processes, so you can sleep in python, but if flixcapacitor knows every process around is waiting for i/o or sleeping, it can speed up time
 62 2018-01-15 09:14:45	0|sipa|*flux
 63 2018-01-15 09:28:42	0|CubicEarths|sipa: You are 33 ?!
 64 2018-01-15 09:29:10	0|sipa|iseems so
 65 2018-01-15 09:29:22	0|aj|wumpus: i'm guessing #11796 will have to wait for 0.17 now?
 66 2018-01-15 09:29:24	0|gribble|https://github.com/bitcoin/bitcoin/issues/11796 | [tests] Functional test naming convention by ajtowns · Pull Request #11796 · bitcoin/bitcoin · GitHub
 67 2018-01-15 09:29:37	0|aj|sipa: happy (belated?) 0x21st then
 68 2018-01-15 09:30:23	0|sipa|aj: about 4 months ago
 69 2018-01-15 09:32:00	0|CubicEarths|I was sure you were older (but for good reasons).
 70 2018-01-15 09:32:17	0|wumpus|aj: I think it makes sense to do that before the branch, to make it easier to backport tests to 0.16
 71 2018-01-15 09:33:01	0|aj|wumpus: yeah. before the 0.16 branch sounds better than before the 0.17 branch too :)
 72 2018-01-15 09:33:11	0|wumpus|I don't think test changes need to pay attention to feature freezes
 73 2018-01-15 09:33:59	0|wumpus|the only drawback of merging it, say, now, would be that some PRs need to rebase, but that's always the case
 74 2018-01-15 09:34:02	0|aj|wumpus: 11796 should be merge-able anytime, only #11774 should case any conflicts or need for rebases
 75 2018-01-15 09:34:08	0|gribble|https://github.com/bitcoin/bitcoin/issues/11774 | [WIP] [tests] Rename functional tests by ajtowns · Pull Request #11774 · bitcoin/bitcoin · GitHub
 76 2018-01-15 09:34:08	0|sipa|i'll try to make a PR for importmulti support for segwit addresses soon; i think we shouldn't have 0.16 (or 16.0?) without
 77 2018-01-15 09:34:45	0|wumpus|sipa: please make an issue so that we can tag it 0.16.0 and not forget about it
 78 2018-01-15 09:34:57	0|wumpus|aj: thanks
 79 2018-01-15 09:35:03	0|aj|wumpus: (i have a script to update 11774 that i run whenever i think of it)
 80 2018-01-15 09:36:37	0|wumpus|aj: I see - so 11796 just prevents new tests from being introduced that violate the new naming convention, clever
 81 2018-01-15 09:37:07	0|aj|wumpus: yeah, it has leeway for a few more violations than already exist too just in case
 82 2018-01-15 09:38:32	0|bitcoin-git|[13bitcoin] 15laanwj pushed 6 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/9501dc27b336...4db16ec82793
 83 2018-01-15 09:38:33	0|bitcoin-git|13bitcoin/06master 141e10854 15John Newbery: [tests] [docs] update README for new test naming scheme
 84 2018-01-15 09:38:33	0|bitcoin-git|13bitcoin/06master 1482b2712 15John Newbery: [tests] move witness util functions to blocktools.py...
 85 2018-01-15 09:38:34	0|bitcoin-git|13bitcoin/06master 147250b4e 15Anthony Towns: [tests] README.md nit fixes
 86 2018-01-15 09:39:05	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11796: [tests] Functional test naming convention (06master...06soft_rename_tests) 02https://github.com/bitcoin/bitcoin/pull/11796
 87 2018-01-15 09:39:44	0|aj|\o/
 88 2018-01-15 09:41:45	0|aj|wumpus: #11862 is definitely not happening 'til 0.17 though, right?
 89 2018-01-15 09:41:47	0|gribble|https://github.com/bitcoin/bitcoin/issues/11862 | [wip] Network specific conf sections by ajtowns · Pull Request #11862 · bitcoin/bitcoin · GitHub
 90 2018-01-15 09:41:53	0|wumpus|aj: agree
 91 2018-01-15 09:41:56	0|sipa|wumpus: will do (create issue)
 92 2018-01-15 09:42:01	0|sipa|yes, agree for 0.17
 93 2018-01-15 13:06:24	0|bitcoin-git|[13bitcoin] 15ericallam opened pull request #12189: [Qt] Display transaction fee with sat/vbyte value in SendCoinsDialog (06master...06sat_vbyte_fee_rate_in_qt) 02https://github.com/bitcoin/bitcoin/pull/12189
 94 2018-01-15 13:27:33	0|wumpus|aj: "INFO: 84 tests not meeting naming conventions (expected 77):" on master now
 95 2018-01-15 13:28:41	0|wumpus|eh not master, but master +#12118, but that doesn't add any functional tests
 96 2018-01-15 13:28:43	0|gribble|https://github.com/bitcoin/bitcoin/issues/12118 | Sort mempool by min(feerate, ancestor_feerate) by sdaftuar · Pull Request #12118 · bitcoin/bitcoin · GitHub
 97 2018-01-15 13:33:04	0|aj|wumpus: yeah, those are from PRs merged over the past couple of months
 98 2018-01-15 13:35:08	0|wumpus|probably needs to be updated to prevent that from being printed all the time
 99 2018-01-15 13:35:44	0|aj|is wallet_address_types.py still failing randomly? https://travis-ci.org/bitcoin/bitcoin/jobs/328994783
100 2018-01-15 13:37:10	0|wumpus|I haven't seen it fail recently on master at least
101 2018-01-15 13:37:15	0|aj|wumpus: EXPECTED_VIOLATION_COUNT in test_runner.py is the change
102 2018-01-15 14:18:38	0|bitcoin-git|[13bitcoin] 15fwolfst opened pull request #12192: Trivial: Issue 12190: Update http URL of MIT license to use https (06master...0612190-UPDATE_MIT_LINK_TO_HTTPS) 02https://github.com/bitcoin/bitcoin/pull/12192
103 2018-01-15 14:37:00	0|bitcoin-git|[13bitcoin] 15laanwj pushed 5 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/4db16ec82793...44080a90a292
104 2018-01-15 14:37:01	0|bitcoin-git|13bitcoin/06master 146773f92 15Suhas Daftuar: Refactor CompareTxMemPoolEntryByDescendantScore
105 2018-01-15 14:37:01	0|bitcoin-git|13bitcoin/06master 149a51319 15Suhas Daftuar: Sort mempool by min(feerate, ancestor_feerate)...
106 2018-01-15 14:37:02	0|bitcoin-git|13bitcoin/06master 147abfa53 15Suhas Daftuar: Add test for new ancestor feerate sort behavior
107 2018-01-15 14:37:45	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12118: Sort mempool by min(feerate, ancestor_feerate) (06master...062018-01-fix-mempool-score) 02https://github.com/bitcoin/bitcoin/pull/12118
108 2018-01-15 15:55:59	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #12193: RPC: Consistently use UniValue.pushKV instead of push_back(Pair()) (karel-3d) (06master...06Mf1801-univalueDeprecatedPair) 02https://github.com/bitcoin/bitcoin/pull/12193
109 2018-01-15 16:20:24	0|promag|is snake case the convention for rpc arguments?
110 2018-01-15 16:30:35	0|wumpus|promag: yes, all of them follow that convention
111 2018-01-15 16:31:19	0|promag|we have some camel case (object options)
112 2018-01-15 16:31:41	0|promag|there are some like "maxtries"
113 2018-01-15 16:31:45	0|wumpus|all the direct arguments do
114 2018-01-15 16:31:46	0|promag|should be max_tries?
115 2018-01-15 16:32:02	0|wumpus|if it was a new call, that should be the case, don't bother changing the interface now
116 2018-01-15 16:32:37	0|promag|so even options should follow snake case
117 2018-01-15 16:32:59	0|wumpus|for new calls, yes, but we don't change the existing API just to confirm to that
118 2018-01-15 16:36:58	0|bitcoin-git|[13bitcoin] 15promag opened pull request #12194: Add change type option to fundrawtransaction (06master...062018-01-fundrawtransaction-changetype) 02https://github.com/bitcoin/bitcoin/pull/12194
119 2018-01-15 17:07:39	0|Tituzin|Good afternoon Guys - I need help with a little problem I have - I opened my Core wallet from February 2014, after syncing all the blocks, I found a sending transaction that was "unconfirmed/not in memory pool" since 2014. I check for txid on the block explorer and there is no info about that transaction. I went ahead and "ABANDONED TRANSACTION". Will I ever get these btc back? I checked both sender and receipient wallets,
120 2018-01-15 17:08:18	0|Tituzin|after hitting "abandon" - now the transaction only says Status: 0/unconfirmed, not in memory pool, abandoned   /  Output index: 1
121 2018-01-15 17:08:45	0|Tituzin|what would be my next step to try and recover it?
122 2018-01-15 17:09:40	0|sipa|Tituzin: https://bitcoin.stackexchange.com
123 2018-01-15 17:12:59	0|alexeyneu|rescan blockchain
124 2018-01-15 17:16:52	0|Tituzin|Thank you Sipa, ill try there - I was hoping a DEV would help but ill try the pagans :D
125 2018-01-15 22:34:08	0|bitcoin-git|13bitcoin/06master 1459f9e2a 15Jonas Schnelli: Use flexible font size for QRCode image address
126 2018-01-15 22:34:08	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/44080a90a292...bbc91b769973
127 2018-01-15 22:34:09	0|bitcoin-git|13bitcoin/06master 14bbc91b7 15Wladimir J. van der Laan: Merge #12173: [Qt] Use flexible font size for QRCode image address...
128 2018-01-15 22:34:57	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12173: [Qt] Use flexible font size for QRCode image address (06master...062018/01/fix_qr_font) 02https://github.com/bitcoin/bitcoin/pull/12173
129 2018-01-15 22:49:30	0|cfields|gcc fixes for non-deterministic code generation among differing host libc's merged upstream: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=2bd421962ff63a8eca179a8fb2c2f898749246c5 :)
130 2018-01-15 22:53:00	0|sipa|cfields: woohoo, a commit in GCC, that's like... geek level 53 unlocked?
131 2018-01-15 22:54:09	0|wumpus|cfields: awesome!
132 2018-01-15 22:54:53	0|cfields|sipa: haha
133 2018-01-15 22:57:23	0|cfields|warren: ^^ may be of interest to you if you're still involved on the Linux/Fedora determinism front
134 2018-01-15 23:03:18	0|luke-jr|sipa: what geek level is unlocked by a commit in Linux? <.<
135 2018-01-15 23:08:15	0|goksinen|hey guys, i wanted to know when is MAST relasing?
136 2018-01-15 23:08:30	0|goksinen|Does anyone have any idea?
137 2018-01-15 23:15:21	0|cfields|luke-jr: Yours are more interesting, but I do have a small cosmetic kernel commit :p
138 2018-01-15 23:18:09	0|wumpus|my kernel commits all have to do with etnaviv I think
139 2018-01-15 23:19:27	0|sipa|luke-jr: 79 i guess
140 2018-01-15 23:19:52	0|cfields|ooh, wumpus is winning
141 2018-01-15 23:20:06	0|sipa|:)
142 2018-01-15 23:20:52	0|luke-jr|cfields: they are? mine seem pretty boring
143 2018-01-15 23:22:07	0|wumpus|sipa: I think a gcc commit should score higher, compilers especially gcc always seemed hocus pocus to me
144 2018-01-15 23:23:16	0|cfields|wumpus: Diving into the source confirmed. It's all voodoo.