1 2016-06-08 00:00:28	0|gmaxwell|Funny that.
  2 2016-06-08 01:12:05	0|adiabat|Hey, wondering if anyone is working on the idea of the "Bloom Filter Digest", like if there's a BIP in the works or anything
  3 2016-06-08 01:12:15	0|adiabat|there was a post in the mailing list about a month ago
  4 2016-06-08 01:58:19	0|Chris_Stewart_5|If I specify a -datadir when launching an instnce of bitcoind, does my bitcoind instance look for a bitcoin.conf inside of my datadir, or ~/.bitcoin/bitcoin.conf?
  5 2016-06-08 02:03:44	0|achow101|Chris_Stewart_5: it looks for it in your specified datadir
  6 2016-06-08 02:07:54	0|Chris_Stewart_5|achow101: Thanks
  7 2016-06-08 02:46:47	0|phantomcircuit|cfields_, travis appears to be borked
  8 2016-06-08 02:47:20	0|cfields_|phantomcircuit: https://github.com/bitcoin/bitcoin/pull/8164 ?
  9 2016-06-08 02:47:23	0|cfields_|or something else?
 10 2016-06-08 02:48:12	0|cfields_|yea, same problem
 11 2016-06-08 02:48:24	0|phantomcircuit|https://github.com/bitcoin/bitcoin/pull/8152
 12 2016-06-08 02:48:50	0|phantomcircuit|the no-wallet test fails and that pr is only touching wallet code
 13 2016-06-08 02:48:55	0|phantomcircuit|so it's definitely a travis failure
 14 2016-06-08 02:49:33	0|cfields_|phantomcircuit: see 8164. master's currently borked, so that will need to be fixed first
 15 2016-06-08 02:49:43	0|phantomcircuit|jonasschnelli, also i can swap the order of the commits in 8152 such that there's never a performance regression even within the pr
 16 2016-06-08 02:50:04	0|phantomcircuit|ah ok
 17 2016-06-08 02:58:37	0|cfields_|wumpus: for backlog, ^^ please check out 8164 when you're around if jonasschnelli doesn't beat you to it :)
 18 2016-06-08 03:42:48	0|GitHub141|[13bitcoin] 15theuni opened pull request #8167: gitian: Ship debug tarballs/zips with debug symbols (06master...06split-debug) 02https://github.com/bitcoin/bitcoin/pull/8167
 19 2016-06-08 07:55:01	0|jonasschnelli|wumpus: ParseInt does use int32_t and not uint32_t... isn't that a problem?
 20 2016-06-08 07:55:18	0|wumpus|do you need the full range of uint32_t?
 21 2016-06-08 07:55:35	0|jonasschnelli|nSequence is uint32_t i guess.
 22 2016-06-08 07:55:46	0|wumpus|if so, we need a ParseUint32
 23 2016-06-08 07:56:11	0|wumpus|I'll make one.
 24 2016-06-08 07:56:29	0|jonasschnelli|Yes. I just saw that there are atoi in bitcoin-tx (before my change) and I just was "continue" that way. But I agree, re-using the ParseInt* stuff is better
 25 2016-06-08 07:56:37	0|wumpus|do you need that atoi change in #8164 to 'unstuck' travis?
 26 2016-06-08 07:56:50	0|jonasschnelli|yes.
 27 2016-06-08 07:57:00	0|wumpus|ok
 28 2016-06-08 07:57:08	0|wumpus|I'll just merge #8164 then
 29 2016-06-08 07:57:10	0|jonasschnelli|yes.
 30 2016-06-08 07:57:18	0|jonasschnelli|We can change it bitcoin-tx wide later
 31 2016-06-08 07:57:32	0|wumpus|but we should move away from using low-level number parsing functions and use the ones in util where available
 32 2016-06-08 07:57:34	0|wumpus|right
 33 2016-06-08 07:57:47	0|jonasschnelli|There are servals atoi
 34 2016-06-08 07:57:54	0|jonasschnelli|and even atoi64
 35 2016-06-08 07:58:22	0|wumpus|the problem is that those functions don't have any error reporting, or range checking, etc
 36 2016-06-08 07:58:42	0|wumpus|or if they do it's annoying to use
 37 2016-06-08 07:58:47	0|wumpus|or even OS dependent
 38 2016-06-08 07:59:28	0|GitHub30|13bitcoin/06master 1486efa30 15Jonas Schnelli: [Bitcoin-Tx] fix missing test fixtures, fix 32bit atoi issue
 39 2016-06-08 07:59:28	0|GitHub30|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/79004d4ae671...0f24eaf253ab
 40 2016-06-08 07:59:29	0|GitHub30|13bitcoin/06master 140f24eaf 15Wladimir J. van der Laan: Merge #8164: [Bitcoin-Tx] fix missing test fixtures, fix 32bit atoi issue...
 41 2016-06-08 07:59:38	0|GitHub188|[13bitcoin] 15laanwj closed pull request #8164: [Bitcoin-Tx] fix missing test fixtures, fix 32bit atoi issue (06master...062016/04/rbf_base) 02https://github.com/bitcoin/bitcoin/pull/8164
 42 2016-06-08 08:01:03	0|jonasschnelli|Yes. And sorry for the travis breaker...
 43 2016-06-08 08:01:36	0|wumpus|I should have waited for travis before merging, I ran the test locally and assumed it'd be ok
 44 2016-06-08 08:03:12	0|jonasschnelli|Yes. Did the same. Haven't though about 32bit issues. But great that we have Travis!
 45 2016-06-08 08:03:26	0|jonasschnelli|A failing travis is always a success. :)
 46 2016-06-08 08:03:49	0|jonasschnelli|going to re-kick failed pulls
 47 2016-06-08 08:27:02	0|GitHub98|[13bitcoin] 15laanwj opened pull request #8168: util: Add ParseUInt32 and ParseUInt64 (06master...062016_06_parseuint) 02https://github.com/bitcoin/bitcoin/pull/8168
 48 2016-06-08 08:27:14	0|wumpus|let's see if this one passes travis, what surprises windows has in store for us...
 49 2016-06-08 08:28:44	0|gmaxwell|Great mysteries of the window--- who know what lies beyond it's curtain rimmed borders.
 50 2016-06-08 08:30:13	0|sipa|the Window kingdom has been in decline for years
 51 2016-06-08 08:30:18	0|wumpus|a perilous landscape full of traps and mines
 52 2016-06-08 08:33:22	0|wumpus|"In locales other than the 'C' locale, other strings may be accepted.  (For example, the thousands separator of the current locale may be supported.)" ... oh crap, I thought strto* avoided the locale madness, I was wrong
 53 2016-06-08 08:34:18	0|wumpus|why is it so difficult to have a number parsing function that does strict parsing and the set of inputs that it accepts is independent of geographical conditions
 54 2016-06-08 08:35:53	0|wumpus|it's almost easier to just write one from scratch than use the C-provided functions
 55 2016-06-08 08:37:09	0|wumpus|in any case using our own utility function makes it easier to swap it out later...
 56 2016-06-08 08:37:17	0|gmaxwell|yea, there are actually a bunch of file formats that are befuxored by this... internationalization was bolted onto the standard library... so there aren't even normal locale independant functions, and you can't change the locale without potentially screwing up other threads.. (well there is the locale_t stuff, but not really portable yet AFAIK)
 57 2016-06-08 08:37:56	0|wumpus|I can imagine - you need to be such a language lawyer to get these things rihgt
 58 2016-06-08 08:38:32	0|wumpus|and yes it was bolted on in retrospect
 59 2016-06-08 08:39:59	0|wumpus|I'm entirely for handling locales where it makes sense, but there's a place for simple deterministic parsing functions (network protocols, file formats) and a place for internationalized handling (such as GUIs), those don't really overlap
 60 2016-06-08 08:41:09	0|gmaxwell|My general principle is to avoid strings in network protocols and file formats. :) but really, textual file formats are often fairly handy.
 61 2016-06-08 08:42:02	0|wumpus|sure, but that's a completely orthogonal discussion, usually you don't get to choose
 62 2016-06-08 08:43:52	0|wumpus|though passing binary numbers on the command line would be interesting :-)
 63 2016-06-08 08:45:22	0|gmaxwell|just don't type anything with any zero bytes...
 64 2016-06-08 08:45:50	0|wumpus|well wouldn't be the first time, passing addresses and code is very popular when trying to get setuid'ed executables to do eh non-standard things
 65 2016-06-08 08:46:23	0|wumpus|yes, those are pesky
 66 2016-06-08 08:47:40	0|gmaxwell|you mean, to do especially awesome things. :)
 67 2016-06-08 08:52:03	0|wumpus|exactly
 68 2016-06-08 08:52:08	0|sipa|wumpus: binary numbers... as in head -n 10011101 file
 69 2016-06-08 08:56:32	0|wumpus|binary, at the speed of one byte per bit!
 70 2016-06-08 10:57:13	0|GitHub32|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/0f24eaf253ab...2156fa23b8ac
 71 2016-06-08 10:57:14	0|GitHub32|13bitcoin/06master 143d3602f 15Jonas Schnelli: Add RPC test for the p2p mempool command in conjunction with disabled bloomfilters
 72 2016-06-08 10:57:14	0|GitHub32|13bitcoin/06master 14beceac9 15Peter Todd: Disable the mempool P2P command when bloom filters disabled...
 73 2016-06-08 10:57:15	0|GitHub32|13bitcoin/06master 142156fa2 15Wladimir J. van der Laan: Merge #8078: Disable the mempool P2P command when bloom filters disabled...
 74 2016-06-08 10:57:23	0|GitHub78|[13bitcoin] 15laanwj closed pull request #8078: Disable the mempool P2P command when bloom filters disabled (06master...062016-05-mempool-p2p-and-bloom) 02https://github.com/bitcoin/bitcoin/pull/8078
 75 2016-06-08 11:02:12	0|GitHub130|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/2156fa23b8ac...67c91f8c4cf7
 76 2016-06-08 11:02:13	0|GitHub130|13bitcoin/06master 146182d10 15Gregory Maxwell: Do not increment nAttempts by more than one for every Good connection....
 77 2016-06-08 11:02:13	0|GitHub130|13bitcoin/06master 14c769c4a 15Gregory Maxwell: Avoid counting failed connect attempts when probably offline....
 78 2016-06-08 11:02:14	0|GitHub130|13bitcoin/06master 1467c91f8 15Wladimir J. van der Laan: Merge #8065: Addrman offline attempts...
 79 2016-06-08 11:02:22	0|GitHub45|[13bitcoin] 15laanwj closed pull request #8065: Addrman offline attempts (06master...06addrman_offline_attempts) 02https://github.com/bitcoin/bitcoin/pull/8065
 80 2016-06-08 11:09:58	0|GitHub196|13bitcoin/06master 142e49448 15Wladimir J. van der Laan: tor: Change auth order to only use HASHEDPASSWORD if -torpassword...
 81 2016-06-08 11:09:58	0|GitHub196|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/67c91f8c4cf7...761cddb69029
 82 2016-06-08 11:09:59	0|GitHub196|13bitcoin/06master 14761cddb 15Wladimir J. van der Laan: Merge #7703: tor: Change auth order to only use password auth if -torpassword...
 83 2016-06-08 11:10:06	0|GitHub18|[13bitcoin] 15laanwj closed pull request #7703: tor: Change auth order to only use password auth if -torpassword (06master...062016_03_auth_order) 02https://github.com/bitcoin/bitcoin/pull/7703
 84 2016-06-08 11:17:16	0|MarcoFalke|wumpus: I have cherry picked the backports for .12 back in April: https://github.com/bitcoin/bitcoin/pull/7938 Hope this is helpful
 85 2016-06-08 11:17:30	0|MarcoFalke|Also, I was wondering if we need any test framework backports
 86 2016-06-08 11:17:41	0|sipa|i would say yes
 87 2016-06-08 11:17:47	0|wumpus|MarcoFalke: thanks!
 88 2016-06-08 11:17:57	0|MarcoFalke|i.e. segwit backport will be different due to missing py3 in .12
 89 2016-06-08 11:18:03	0|sipa|i think 0
 90 2016-06-08 11:18:14	0|sipa|i think 0.12 should be uograded to py3 as well
 91 2016-06-08 11:18:17	0|wumpus|philosophy for the test framework should be: everything that can run against 0.12 should run against 0.12
 92 2016-06-08 11:18:20	0|wumpus|agree with sipa
 93 2016-06-08 11:18:49	0|sipa|of course, if a test requires an rpc that didn't exist in 0.12 yet
 94 2016-06-08 11:18:55	0|sipa|then probably not
 95 2016-06-08 11:18:55	0|wumpus|there is no reason to be exceedingly careful for regressions with backports of test changes
 96 2016-06-08 11:18:57	0|MarcoFalke|Ok, will have a look tonight. Will be quite a huge diff.
 97 2016-06-08 11:19:06	0|wumpus|yeah, no problem
 98 2016-06-08 11:19:10	0|sipa|backporting tests never risks breakjng anything :)
 99 2016-06-08 11:19:21	0|MarcoFalke|Will open a separate pull, just in case
100 2016-06-08 11:19:24	0|sipa|... on the contrary, it may catch bugs in backports
101 2016-06-08 11:20:31	0|wumpus|agreed, better to do so in a separate PR, due to the difference in review density
102 2016-06-08 11:21:24	0|MarcoFalke|sipa: The python 3 switch for the segwit test was a single commit: https://github.com/sipa/bitcoin/commit/a7eeee1c07b5283c0984fcdaac04faac2d93b2e3. So in case I choke at backporting, you may as well not include those in the backport.
103 2016-06-08 11:30:34	0|GitHub9|[13bitcoin] 15jonasschnelli opened pull request #8169: OSX diskimages need 0775 folder permissions (06master...062016/06/fix_gitian_osx) 02https://github.com/bitcoin/bitcoin/pull/8169
104 2016-06-08 12:01:38	0|GitHub172|[13bitcoin] 15laanwj pushed 7 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/761cddb69029...a7c41f2de03c
105 2016-06-08 12:01:39	0|GitHub172|13bitcoin/06master 141b9e6d3 15Pieter Wuille: Add support for unique_ptr and shared_ptr to memusage
106 2016-06-08 12:01:39	0|GitHub172|13bitcoin/06master 148d39d7a 15Pieter Wuille: Switch CTransaction storage in mempool to std::shared_ptr
107 2016-06-08 12:01:40	0|GitHub172|13bitcoin/06master 14dbfb426 15Pieter Wuille: Optimize the relay map to use shared_ptr's...
108 2016-06-08 12:01:48	0|GitHub0|[13bitcoin] 15laanwj closed pull request #8126: std::shared_ptr based CTransaction storage in mempool (06master...06sharedmempool) 02https://github.com/bitcoin/bitcoin/pull/8126
109 2016-06-08 12:02:33	0|GitHub153|[13bitcoin] 15laanwj closed pull request #7530: autogen.sh: check for libtool before automake fails to find it (06master...06libtool-check) 02https://github.com/bitcoin/bitcoin/pull/7530
110 2016-06-08 12:15:18	0|GitHub56|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/a7c41f2de03c...75ec320a0d53
111 2016-06-08 12:15:19	0|GitHub56|13bitcoin/06master 14fa7f4f5 15MarcoFalke: [rpc] fundrawtransaction feeRate: Use BTC/kB...
112 2016-06-08 12:15:19	0|GitHub56|13bitcoin/06master 14faf82e8 15MarcoFalke: [rpc] fundrawtransaction: Fix help text and interface
113 2016-06-08 12:15:20	0|GitHub56|13bitcoin/06master 1475ec320 15Wladimir J. van der Laan: Merge #8153: [rpc] fundrawtransaction feeRate: Use BTC/kB...
114 2016-06-08 12:15:22	0|GitHub172|[13bitcoin] 15laanwj closed pull request #8144: [rpc] fundrawtransaction: Fix help text (06master...06Mf1606-rpcDoc) 02https://github.com/bitcoin/bitcoin/pull/8144
115 2016-06-08 12:15:28	0|GitHub0|[13bitcoin] 15laanwj closed pull request #8153:  [rpc] fundrawtransaction feeRate: Use BTC/kB  (06master...06Mf1606-univalAny) 02https://github.com/bitcoin/bitcoin/pull/8153
116 2016-06-08 12:26:00	0|GitHub43|[13bitcoin] 15laanwj pushed 7 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/75ec320a0d53...6a034ed89891
117 2016-06-08 12:26:01	0|GitHub43|13bitcoin/06master 140385202 15fanquake: [depends] ccache 3.2.5
118 2016-06-08 12:26:01	0|GitHub43|13bitcoin/06master 142b2d52e 15fanquake: [depends] Freetype 2.6.3...
119 2016-06-08 12:26:02	0|GitHub43|13bitcoin/06master 14bd3cbd5 15fanquake: [depends] ZeroMQ 4.1.4
120 2016-06-08 12:26:05	0|GitHub64|[13bitcoin] 15laanwj closed pull request #7993: [depends] Bump Freetype, ccache, ZeroMQ, miniupnpc, expat (06master...06depends-no-sourceforge) 02https://github.com/bitcoin/bitcoin/pull/7993
121 2016-06-08 12:55:07	0|GitHub34|[13bitcoin] 15sipa opened pull request #8170: Remove lookup-tx-by-utxo functionality (06master...06betternotxindex) 02https://github.com/bitcoin/bitcoin/pull/8170
122 2016-06-08 13:14:46	0|jonasschnelli|Hmm....
123 2016-06-08 13:15:19	0|jonasschnelli|another cleanup required for one of my pulls..
124 2016-06-08 13:15:22	0|jonasschnelli|*sight*
125 2016-06-08 13:16:07	0|sipa|sight is good
126 2016-06-08 13:16:53	0|jonasschnelli|*sigh* :-)
127 2016-06-08 13:17:10	0|jonasschnelli|wumpus: can you extend your ParseUInt32 to univalue?
128 2016-06-08 13:17:38	0|wumpus|why would univalue need to parse unsigned 32 bit integers?
129 2016-06-08 13:18:00	0|jonasschnelli|createrawtransactions new sequence number input per vin does not support unsigned
130 2016-06-08 13:18:10	0|wumpus|we treat all integers as 64 bit signed
131 2016-06-08 13:18:15	0|jonasschnelli|So > 0x7FFFFFFF will be rejected.. :(
132 2016-06-08 13:18:27	0|wumpus|which should be enough to support the full 32 bit unsigned range
133 2016-06-08 13:18:31	0|jonasschnelli|It calls int UniValue::get_int() const
134 2016-06-08 13:18:41	0|jonasschnelli|which does a `if (!ParseInt32(getValStr(), &retval))`
135 2016-06-08 13:18:52	0|jonasschnelli|and throws > 0x7FFFFFFF
136 2016-06-08 13:18:53	0|wumpus|oh, just use the 64-bit one then
137 2016-06-08 13:19:14	0|sipa|use get_int64(), and rangecheck the result
138 2016-06-08 13:19:16	0|wumpus|I don't think we should be adding more types of integers to JSON, that just complicates things
139 2016-06-08 13:19:27	0|jonasschnelli|Right... let me try
140 2016-06-08 13:19:40	0|wumpus|our previous JSON parsing library didn't even have a 32-bit signed integer get
141 2016-06-08 13:25:49	0|jonasschnelli|should we allow -1 as sequence numbers? Pretty convenient.
142 2016-06-08 13:28:17	0|wumpus|wouldn't be very consistent if we do strict 32-bit unsigned int parsing for the -tx
143 2016-06-08 13:29:44	0|jonasschnelli|yes. Let me do a <0 check
144 2016-06-08 13:30:32	0|wumpus|I'd say sequence number is a positive value, and that should be enforced in the API; though -1 is convenient, negative numbers are slightly ambigious
145 2016-06-08 13:31:18	0|wumpus|we also print sequence numbers as unsigned int I hope?
146 2016-06-08 13:38:57	0|jonasschnelli|wumpus: at least decoderawtransaction does this correct.
147 2016-06-08 13:39:07	0|wumpus|good, thanks for checking
148 2016-06-08 13:39:15	0|jonasschnelli|heh: entry.push_back(Pair("sequence", (uint64_t)txin.nSequence));
149 2016-06-08 13:39:41	0|jonasschnelli|I guess UniValues has no uint32 pair?
150 2016-06-08 13:40:10	0|jonasschnelli|but (uint64_t)txin.nSequence is fine IMO
151 2016-06-08 13:40:17	0|wumpus|yea, please just use 64 bit signed integeres with JSON
152 2016-06-08 13:41:41	0|wumpus|there's no need to support other integer types - certainly not for output, for input a specific range checked get function could be mildly useful, but that probably belongs at the application (argument checking) side, not in univalue itself
153 2016-06-08 13:44:04	0|GitHub34|[13bitcoin] 15jonasschnelli opened pull request #8171: [RPC] Fix createrawtx sequence number unsigned int parsing (06master...062016/06/fix_crt) 02https://github.com/bitcoin/bitcoin/pull/8171
154 2016-06-08 13:44:34	0|GitHub123|[13bitcoin] 15sipa pushed 5 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/6a034ed89891...66ed450d771a
155 2016-06-08 13:44:35	0|GitHub123|13bitcoin/06master 1472cd6b2 15Luke Dashjr: qa/rpc-tests: bip9-softforks: Add tests for getblocktemplate versionbits updates
156 2016-06-08 13:44:35	0|GitHub123|13bitcoin/06master 14d3df40e 15Luke Dashjr: Implement BIP 9 GBT changes...
157 2016-06-08 13:44:36	0|GitHub123|13bitcoin/06master 149879060 15Luke Dashjr: getblocktemplate: Explicitly handle the distinction between GBT-affecting softforks vs not
158 2016-06-08 13:44:39	0|GitHub100|[13bitcoin] 15sipa closed pull request #7935: Versionbits: GBT support (06master...06gbt_bip9) 02https://github.com/bitcoin/bitcoin/pull/7935
159 2016-06-08 13:45:54	0|GitHub68|[13bitcoin] 15sipa opened pull request #8172: Fix two warnings for comparison between signed and unsigned (06master...06fixunsigned) 02https://github.com/bitcoin/bitcoin/pull/8172
160 2016-06-08 13:52:51	0|GitHub73|[13bitcoin] 15laanwj opened pull request #8173: test: Add more test vectors for siphash (06master...062016_06_siphash_testing) 02https://github.com/bitcoin/bitcoin/pull/8173
161 2016-06-08 13:55:20	0|GitHub7|[13bitcoin] 15sipa closed pull request #8086: Use SipHash for node eviction (06master...06moresiphash) 02https://github.com/bitcoin/bitcoin/pull/8086
162 2016-06-08 14:26:20	0|_anthony_|woohoo it's like I've built a time machine
163 2016-06-08 14:26:25	0|_anthony_|hello all
164 2016-06-08 14:28:19	0|_anthony_|BtcDrak said that I can be a core dev
165 2016-06-08 14:28:21	0|sipa|hello
166 2016-06-08 14:28:26	0|_anthony_|hi sipa
167 2016-06-08 14:33:55	0|achow101|_anthony_: anyone can be a "core dev". You just need to submit PRs to Bitcoin Core
168 2016-06-08 14:34:18	0|instagibbs|please don't forget review of PRs
169 2016-06-08 14:34:20	0|_anthony_|OK. What PRs do you want me to work on?
170 2016-06-08 14:34:45	0|_anthony_|Is there any internals documentation that needs to be worked on?
171 2016-06-08 14:36:44	0|wumpus|generally all PRs and issues that are open are fair game, of course reviewing segwit or compact blocks etc may be the most urgent
172 2016-06-08 14:37:20	0|instagibbs|when is freeze for 0.13
173 2016-06-08 14:37:54	0|wumpus|segwit: https://github.com/bitcoin/bitcoin/pull/8149  compact blocks: https://github.com/bitcoin/bitcoin/pull/8068
174 2016-06-08 14:38:04	0|wumpus|instagibbs: feature freeze is june 16
175 2016-06-08 14:38:28	0|wumpus|release schedule for 0.13.0: https://github.com/bitcoin/bitcoin/issues/7679
176 2016-06-08 14:38:40	0|instagibbs|I'll try and make time to review CB soon
177 2016-06-08 14:39:21	0|_anthony_|hmm I definitely need to get more familiar with the way the code is layed out...maybe while reviewing segwit I can do that
178 2016-06-08 14:39:45	0|btcdrak|welcome  _anthony_
179 2016-06-08 14:40:06	0|instagibbs|_anthony_, that's a bear of a first PR to review :)
180 2016-06-08 14:40:10	0|_anthony_|thanks btcdrak
181 2016-06-08 14:40:18	0|sipa|_anthony_: usually the best way to learn a codebase is by contributing yourself... find relatively simple improvements, and try to fix them
182 2016-06-08 14:40:41	0|sipa|_anthony_: reviewing changes to a codebase that you're not familiar with is not so effective i think
183 2016-06-08 14:40:48	0|_anthony_|I went through some of the open issues yesterday...it looks like some of them should be closed
184 2016-06-08 14:41:09	0|instagibbs|Writing tests can be good practice too.
185 2016-06-08 14:41:11	0|wumpus|_anthony_: that can certainly happen, feel free to let us know if that is the case
186 2016-06-08 14:41:32	0|_anthony_|k I'll keep a list next time I come across one
187 2016-06-08 14:41:41	0|wumpus|sometimes an issue is fixed but forgotten about, I tend to go over the full list at least monthly but some things slip through
188 2016-06-08 15:42:36	0|GitHub12|13bitcoin/06master 142d83013 15Jonas Schnelli: Add support for dnsseeds with option to filter by servicebits
189 2016-06-08 15:42:36	0|GitHub12|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/66ed450d771a...cd0c5135ab22
190 2016-06-08 15:42:37	0|GitHub12|13bitcoin/06master 14cd0c513 15Pieter Wuille: Merge #8083: Add support for dnsseeds with option to filter by servicebits...
191 2016-06-08 15:42:46	0|GitHub53|[13bitcoin] 15sipa closed pull request #8083: Add support for dnsseeds with option to filter by servicebits (06master...062016/05/dnsfilter) 02https://github.com/bitcoin/bitcoin/pull/8083
192 2016-06-08 15:44:22	0|cfields_|jonasschnelli: great work on ^^
193 2016-06-08 15:44:36	0|sipa|petertodd, luke-jr: subtle ping to update your dns seeds to support service bits filtering
194 2016-06-08 15:46:24	0|jonasschnelli|cfields_: the bitcoin part was easy, the part on the bitcoin-seeder was more complex. :)
195 2016-06-08 15:46:33	0|jonasschnelli|Also code i'm not use to play around with.
196 2016-06-08 15:47:11	0|jonasschnelli|But as always, sipa made the important last changes/fixes. :)
197 2016-06-08 15:47:16	0|cfields_|jonasschnelli: yea, i took a quick look. steep learning curve there
198 2016-06-08 15:50:26	0|sipa|i wrote it in a week while i was ill
199 2016-06-08 15:50:44	0|sipa|certainly not the best code i've written :)
200 2016-06-08 15:53:34	0|cfields_|heh, well it's apparently pretty bullet-proof. can't argue with that :)
201 2016-06-08 16:08:25	0|cfields_|ok, I was trying to avoid this because i know everyone's busy with a dozen other things, but I'll be away for a while after Friday, and I'm hoping to get as much net refactor stuff as possible knocked out first...
202 2016-06-08 16:08:34	0|cfields_|so... review begs for #8128 and #8085
203 2016-06-08 16:09:44	0|cfields_|(and taking requests for anything I should prioritize before leaving)
204 2016-06-08 16:33:01	0|GitHub88|[13bitcoin] 15sipa pushed 6 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/cd0c5135ab22...4286f4302514
205 2016-06-08 16:33:02	0|GitHub88|13bitcoin/06master 14053930f 15Patrick Strateman: Avoid recalculating vchKeyedNetGroup in eviction logic....
206 2016-06-08 16:33:02	0|GitHub88|13bitcoin/06master 149bf156b 15Pieter Wuille: Support SipHash with arbitrary byte writes
207 2016-06-08 16:33:03	0|GitHub88|13bitcoin/06master 14c31b24f 15Pieter Wuille: Use 64-bit SipHash of netgroups in eviction
208 2016-06-08 16:33:07	0|GitHub140|[13bitcoin] 15sipa closed pull request #8173: Use SipHash for node eviction (cont'd) (06master...062016_06_siphash_testing) 02https://github.com/bitcoin/bitcoin/pull/8173
209 2016-06-08 16:54:48	0|jonasschnelli|Is there a way within CWallet / CWalletTx to detect which of the tx.vout's is the change output if the wtx is a spend-to-myself?
210 2016-06-08 16:55:02	0|jonasschnelli|AddressBook lookup?
211 2016-06-08 16:57:02	0|luke-jr|yes
212 2016-06-08 16:57:34	0|jonasschnelli|So I need to solve the pubkey and check if its P2PKH (or different), get the CKeyID and do an addressbook lookup...
213 2016-06-08 16:57:40	0|jonasschnelli|hmm... not good. :)
214 2016-06-08 16:58:20	0|jonasschnelli|s/solve the pubkey/use the solver on the scriptPubKey to retrieve the address
215 2016-06-08 16:58:52	0|sipa|jonasschnelli: no, you convert to a CTxDestination and then check whether that's in the address book
216 2016-06-08 16:59:19	0|jonasschnelli|sipa: with ExtractDestination()?
217 2016-06-08 16:59:26	0|sipa|yes
218 2016-06-08 16:59:46	0|jonasschnelli|Okay.. that sounds feasible.
219 2016-06-08 17:02:41	0|cfields_|sipa: wrt #7749, do we want to maybe filter the addresses we send in response to getaddr based on the current connection's common services? or maybe prioritize those somehow?
220 2016-06-08 17:13:50	0|jl2012|is it possible to use signrawtransaction to sign a multisig tx with flags other than SIGHASH_ALL?
221 2016-06-08 17:15:07	0|gmaxwell|Yes.
222 2016-06-08 17:15:18	0|gmaxwell|it takes an argument to set the flags it will sign with.
223 2016-06-08 17:22:22	0|NicolasDorier|sipa: long story short bytespersigop enforced in AcceptToMempool broke some use case on upper layer (https://github.com/bitcoin/bitcoin/issues/8079) we have a simple way to fix it, but it would require to count signatures for a transaction a second time accuratly.  Do you think it would be a problem performance wise ? I don't think so but maybe I am missing
224 2016-06-08 17:22:22	0|NicolasDorier|something.
225 2016-06-08 17:24:32	0|jl2012|gmaxwell: the sighash flag is the 4th argument. 1st argument is the unsigned tx. However, when I use [] [] as the 2nd and 3rd arguments, it fails to sign
226 2016-06-08 17:25:23	0|jl2012|without any optional arguments, it signs normally
227 2016-06-08 17:25:58	0|jl2012|btw i'm signing a P2SH-P2WSH
228 2016-06-08 17:45:49	0|NicolasDorier|oh whatever, I'm pretty sure it can't be a perf problem, as the second count is done only on a very specific case. nevermind
229 2016-06-08 17:46:42	0|sipa|NicolasDorier: i don't understand the solution you suggest
230 2016-06-08 17:47:50	0|NicolasDorier|sipa: Well basically bytespersig use GetLegacySigCount which overshoot multisig real signature count. Because of that, it broke an upper layer protocol (counteryparty)
231 2016-06-08 17:47:53	0|NicolasDorier|the solution
232 2016-06-08 17:48:37	0|NicolasDorier|would be "if(nSigOps > MAX_STANDARD_TX_SIGOPS)", then you count signature again accurately, and use such count for calculating if bytespersigop is reached or not
233 2016-06-08 17:48:44	0|sipa|heh, does counterparty still e ist
234 2016-06-08 17:48:54	0|sipa|i see
235 2016-06-08 17:48:57	0|sipa|that would work
236 2016-06-08 17:49:01	0|NicolasDorier|well, I'm not using it, but yeah it seems very much alive
237 2016-06-08 17:49:08	0|sipa|:(
238 2016-06-08 17:49:15	0|sipa|anyway, sounds like a good solution
239 2016-06-08 17:49:20	0|NicolasDorier|ok cool
240 2016-06-08 17:53:07	0|rubensayshi|counterparty uses it as fallback when > 80 bytes, which is 0.0x% or something
241 2016-06-08 17:56:16	0|gmaxwell|People involved with counterparty have told me they intend for counterparty to replace the bitcoin currency because the distribution of bitcoins is "unfair" and counterparty is "more equitable"-- I don't think it's accurate to describe it as an "upper layer" system, it's a system that explicitly is in competition with the bitcoin currency.
242 2016-06-08 18:02:12	0|sipa|NicolasDorier: your solution does not work, because it reintroduces the problem that the original PR was intended to fix
243 2016-06-08 18:02:53	0|sipa|NicolasDorier: the consensus rules count those as 20 sigops; if for mining purposes do not count it as 20, the attack reappears
244 2016-06-08 18:04:07	0|sdaftuar|sipa: doesn't the code as merged still allow for an attack, as you could fill up 400kb of block space with 20k sigops?
245 2016-06-08 18:04:52	0|sipa|sdaftuar: hmm?
246 2016-06-08 18:05:18	0|sipa|20k sigops should be counted as 1 MB, no?
247 2016-06-08 18:05:37	0|sdaftuar|sorry i think i phrased poorly.  at 20bytes/sigop, you could hit the 20k sigops limit with only 400kb of transactions
248 2016-06-08 18:05:51	0|sipa|it should be 50 bytes/sigop
249 2016-06-08 18:05:54	0|sdaftuar|yes
250 2016-06-08 18:06:03	0|sdaftuar|unless there are valid use cases which we'd preclude, that is?
251 2016-06-08 18:06:18	0|sdaftuar|but regardless we should have had this discussion when that PR was merged.  i have no idea where 20 comes from
252 2016-06-08 18:06:34	0|sdaftuar|or what the valid use cases are...
253 2016-06-08 18:06:43	0|sipa|i think i assumed that number was the correct translation factor when it was merged
254 2016-06-08 18:07:30	0|sipa|but dropping transactions that go over the limit is wrong, i think
255 2016-06-08 18:07:54	0|sipa|we should just count them as if they were the correspondig size
256 2016-06-08 18:08:08	0|sdaftuar|you mean for feerate purposes?
257 2016-06-08 18:10:35	0|gmaxwell|thats what I argued for forever but there was some reason people didn't like it... convert each limit to a feerate, and take the worst... under the approximation that whatever is worst will be the limiting factor.
258 2016-06-08 18:10:58	0|sdaftuar|that approximation doesn't hold in CreateNewBlock, most of the time, i'd think
259 2016-06-08 18:11:15	0|sdaftuar|most of the time you're nowhere near the sigops limit
260 2016-06-08 18:11:25	0|gmaxwell|it doesn't, but the size is the worst most of the time, so it doesn't matter except for excpetional transactions.
261 2016-06-08 18:11:30	0|sipa|yes, this is the nonlinear optimization problem again
262 2016-06-08 18:11:45	0|paveljanik|sipa, thanks for fixing the warnings!
263 2016-06-08 18:11:55	0|sipa|but if you use the same count for mining and for relay/priority, there is no problem i think
264 2016-06-08 18:12:37	0|sipa|at least you wouldn't lose money over it as a miner
265 2016-06-08 18:12:48	0|sdaftuar|well miners woulnd't be doing the optimal thing?
266 2016-06-08 18:13:39	0|helo|they'll intend to do the optimal thing, at least
267 2016-06-08 18:15:12	0|sipa|sdaftuar: right, suboptimal, but not susceptible to losing a majority of yiur available block space
268 2016-06-08 18:16:38	0|gmaxwell|Suboptimal though only in the presence of transactions whos sigops cost would dominate their size cost.
269 2016-06-08 18:16:42	0|sdaftuar|yeah maybe that's good enough, and better than the status quo
270 2016-06-08 18:19:06	0|gmaxwell|It's my belief (and hope) that the other limits are set so high that they should never come into effect in practice.
271 2016-06-08 18:19:25	0|gmaxwell|(though this isn't true if people use bare multisig, but they mostly don't)
272 2016-06-08 18:20:57	0|sipa|the fact that this problem only got detected so many months after 0.12 shows that probably not many people use bare multisig...
273 2016-06-08 18:23:11	0|GitHub47|[13bitcoin] 15laanwj opened pull request #8175: gitian: Add --disable-bench to config flags for windows (06master...062016_06_disable_bench_windows) 02https://github.com/bitcoin/bitcoin/pull/8175
274 2016-06-08 18:31:36	0|rubensayshi|offtopic; gmaxwell, I've never heard any1 say counterparty competes with bitcoin, it's focus is tokens (and soon EVM), it would be insane to think it could compete with bitcoin (considering the reduced efficiency)
275 2016-06-08 18:32:21	0|rubensayshi|sipa, I wouldn't find it odd if you guys would decide to block bare multisig from isstandard, but this check wasn't intended that way and the result did
276 2016-06-08 18:32:53	0|rubensayshi|though there might be people still  using it, and I don't see it being isstandard as such a big problem
277 2016-06-08 18:33:29	0|sipa|rubensayshi: agree, i think there are good reasons to make it nonstandard, but it should happen intentionally and after communication, not as an unintended side effect
278 2016-06-08 18:34:25	0|rubensayshi|the consensus rules count bare multisig as 20 sigops, and considering it's part of consensus should continue to do so
279 2016-06-08 18:34:45	0|rubensayshi|I guess the reason why we don't properly count the sigops to begin with is because it's been part of consensus since day 1
280 2016-06-08 18:35:18	0|gmaxwell|it wasn't a part of consensus since day 1, </pedantic>
281 2016-06-08 18:35:27	0|rubensayshi|oh?
282 2016-06-08 18:36:50	0|sipa|i assume it was introeuced somewhere in 2010
283 2016-06-08 18:37:35	0|sipa|whether they were part of the consensus rules on day 1 is also irrelevant; what matters if they are part of consensus now :)
284 2016-06-08 18:39:54	0|rubensayshi|ok, but changing the `bytespersigop` check in AcceptToMempool to use `fAccurate=True` shouldn't be a problem right?
285 2016-06-08 18:40:25	0|gmaxwell|that would defeat the fix against the bloat attack.
286 2016-06-08 18:40:33	0|gmaxwell|The counting has to work exactly as the consensus rule does.
287 2016-06-08 18:45:30	0|rubensayshi|hmm, the consensus prevents a block being larger than 1mb or 20k sigops, so you don't want to accept any txs that would tip over the balance to reaching the 20k sigops before you'd reach 1mb?
288 2016-06-08 18:46:04	0|rubensayshi|as in; to optimize fees?
289 2016-06-08 18:46:39	0|gmaxwell|rubensayshi: thats right.. there was some attacker a while back flooding the network with transactions that used huge amounts of sigops, which would cause miners to needlessly produce small blocks.
290 2016-06-08 18:47:06	0|gmaxwell|there are multiple ways to address that.
291 2016-06-08 18:47:11	0|rubensayshi|ok so I guess I get sipa's point, because we rely on fee/size and not on sigops/size when that's higher
292 2016-06-08 18:57:18	0|rubensayshi|so there's no way to bring back bare multisig other than miners choosing to run with a lower `bytespersigop` (but you just said the default should be 50, not the current 20 to begin with) or changing the consensus rule where bare multisig is counted as 20 sigops?
293 2016-06-08 18:58:23	0|gmaxwell|the broken counting was a softfork added in sept 2010, in ~0.3.12.
294 2016-06-08 18:59:55	0|rubensayshi|so the only valid option would be to improve selecting TXs for blocks in a way that it won't use TXs with high sigops/bytes if it would result in not having a full block so that the check doesn't have to be in the mempool policy
295 2016-06-08 19:00:05	0|rubensayshi|which is ...
296 2016-06-08 19:00:16	0|rubensayshi|way to much complexity and too big of a task
297 2016-06-08 19:04:22	0|gmaxwell|20 is more permissive than 50, fwiw.
298 2016-06-08 19:04:52	0|gmaxwell|there was a discussion on IRC about setting it, and 20 seemsed to be the lowest that it could be set without outright enabling that attack.
299 2016-06-08 19:05:46	0|sdaftuar|gmaxwell: pointer to the IRC conversation?  i looked and never found any discussion
300 2016-06-08 19:05:57	0|gmaxwell|rubensayshi: right, and generally we consider bare multisig undesirable for unrelated reasons too, and there is longstanding discussion toward moving to make it non-standard... so doesn't really justify a bunch of complexity to try to work around it.
301 2016-06-08 19:06:15	0|rubensayshi|I guess it should just be made non standard then
302 2016-06-08 19:06:28	0|rubensayshi|which it essentially is now
303 2016-06-08 19:07:28	0|rubensayshi|how about some extra bytes for opreturn then :P ?
304 2016-06-08 19:10:19	0|gmaxwell|sdaftuar: turns out searching for the number 20 is really hard.
305 2016-06-08 19:10:40	0|btcdrak|maybe sigop?
306 2016-06-08 19:11:32	0|btcdrak|gmaxwell: how about this? https://botbot.me/freenode/bitcoin-core-dev/2015-10-22/?msg=52464204&page=1
307 2016-06-08 19:13:15	0|btcdrak|another conversation starts here https://botbot.me/freenode/bitcoin-core-dev/2015-11-04/?msg=53446658&page=2
308 2016-06-08 19:14:08	0|luke-jr|regardless of what we do to fix bytespersigop, I think we should disable bare multisig by default; with that in mind, *which* solution we go with seems less important
309 2016-06-08 19:15:24	0|luke-jr|(but IMO the better fix is to simply count CHECKMULTISIG correctly for this purpose, since the goal is spam prevention, and higher fees don't matter in that case)
310 2016-06-08 19:15:58	0|GitHub83|[13bitcoin] 15luke-jr opened pull request #8176: [0.12.x]: Versionbits: GBT support (060.12...06gbt_bip9-0.12.x) 02https://github.com/bitcoin/bitcoin/pull/8176
311 2016-06-08 19:17:07	0|luke-jr|rubensayshi: what happened to OP_RETURN counterparty?
312 2016-06-08 19:17:15	0|gmaxwell|it isn't about charging more fees, the whole attack was causing miners to produce needlessly small blocks because they thought sigopbloat txn were more attractive to produce than they were.
313 2016-06-08 19:17:39	0|gmaxwell|if an attacker had to pay as much to 'fill' a block that way as they would with ordinary transactions, then it's no longer an interesting attack vector.
314 2016-06-08 19:17:44	0|rubensayshi|luke-jr, literally 99.988% of CP txs are opreturn
315 2016-06-08 19:18:07	0|btcdrak|luke-jr: they use OP_RETURN for messages < 80 bytes which is most of them.
316 2016-06-08 19:18:12	0|luke-jr|rubensayshi: why not 100%?
317 2016-06-08 19:18:47	0|luke-jr|rubensayshi: is there a good way we could teach Core to identify CP OP_RETURN separate from spam OP_RETURN, so we can allow longer lengths for CP only?
318 2016-06-08 19:19:12	0|rubensayshi|is there a reason not to change isstandard to allow opreturn with more data?
319 2016-06-08 19:19:27	0|rubensayshi|they dont polute utxo set and are prunable
320 2016-06-08 19:19:31	0|rubensayshi|and fee is paid for them
321 2016-06-08 19:19:48	0|gmaxwell|rubensayshi: Bitcoin is a currency not a public shared database.
322 2016-06-08 19:19:56	0|sipa|you're storing data on my disk, without benefitting me or the bitcoin ecosystem
323 2016-06-08 19:20:28	0|btcdrak|gmaxwell: what concerns me is if systems resort to bloating the UTXO with unspendable transactions as a way to encode >80 bytes.
324 2016-06-08 19:20:45	0|gmaxwell|btcdrak: they're not unspendable AFAIK.
325 2016-06-08 19:20:47	0|luke-jr|btcdrak: it seems they currently use spendable CHECKMULTISIGs
326 2016-06-08 19:20:56	0|rubensayshi|the bare multisig are spendable btw
327 2016-06-08 19:20:58	0|luke-jr|1-of-2 with the 2nd key up to 500 or so bytes
328 2016-06-08 19:21:07	0|gmaxwell|though if they were we should simply filter them out generally.
329 2016-06-08 19:21:07	0|rubensayshi|that's the reason to use bare multisig, they're 1-of-3 and the 3rd key is a real key
330 2016-06-08 19:21:35	0|rubensayshi|the last resort is pubkeyhash encoding ...
331 2016-06-08 19:21:48	0|luke-jr|we could probably enforce a pubkey format for bare multisig even when they're enabled, but nobody afaik is legitimately using it, so might as well just disable it by default
332 2016-06-08 19:22:05	0|btcdrak|gmaxwell: pubkeyhash encoding is unspendable afaik
333 2016-06-08 19:22:23	0|luke-jr|pubkeyhash encoding can't do >80 bytes anyway?
334 2016-06-08 19:22:27	0|rubensayshi|yea
335 2016-06-08 19:22:31	0|rubensayshi|100s of outputs ...
336 2016-06-08 19:22:34	0|luke-jr|-.-
337 2016-06-08 19:22:36	0|rubensayshi|all unspendable
338 2016-06-08 19:22:56	0|luke-jr|sigh, maybe we really do need p2sh^2 sooner rather than later
339 2016-06-08 19:23:06	0|rubensayshi|the bare multisig was perfect tbh, because we could clean the outputs
340 2016-06-08 19:23:18	0|btcdrak|it really is about the lesser of the evils. I would say a slightly larger OP_RETURN is preferable than unspendable junk
341 2016-06-08 19:23:25	0|rubensayshi|as a fallback to opreturn that is
342 2016-06-08 19:23:29	0|luke-jr|[19:18:46] <luke-jr> rubensayshi: is there a good way we could teach Core to identify CP OP_RETURN separate from spam OP_RETURN, so we can allow longer lengths for CP only?
343 2016-06-08 19:23:36	0|gmaxwell|rubensayshi: you should have your own network, and stop storing data unrelated to bitcoin in the bitcoin network.
344 2016-06-08 19:23:49	0|gmaxwell|The OP_RETURN as standard facility was intended to store _commitments_ not data.
345 2016-06-08 19:23:59	0|rubensayshi|luke-jr, is there a way you won't change that to drop all of them the next release xD?
346 2016-06-08 19:24:23	0|rubensayshi|gmaxwell, I'm just a script kiddie who dropped by a project that needed some work and sounded fun to do
347 2016-06-08 19:24:38	0|rubensayshi|I didn't come up with this stuff xD
348 2016-06-08 19:24:40	0|gmaxwell|rubensayshi: :)
349 2016-06-08 19:24:43	0|btcdrak|:D
350 2016-06-08 19:24:44	0|rubensayshi|I just get the bug reports
351 2016-06-08 19:24:47	0|gmaxwell|rubensayshi: but you could help rescue it. :)
352 2016-06-08 19:24:53	0|gmaxwell|Dare to dream.
353 2016-06-08 19:25:02	0|btcdrak|sidechains...
354 2016-06-08 19:25:21	0|rubensayshi|hehe
355 2016-06-08 19:25:40	0|gmaxwell|it's not even a 'sidechain'-- it's a seperate currency/asset tracking network. :)
356 2016-06-08 19:25:54	0|luke-jr|rubensayshi: believe it or not, the 0.12 thing was an accident in affecting CP
357 2016-06-08 19:26:22	0|gmaxwell|indeed, that wasn't intended. if we had intended to block CP then it would be blocked completely.
358 2016-06-08 19:26:25	0|rubensayshi|I gave you the benefit of doubt luke-jr, but not having any tests for it makes it look funky (I'll write some tests 2morrow for it!)
359 2016-06-08 19:26:42	0|adiabat|is there a recommended / reliable way to put this data in the witness stack?
360 2016-06-08 19:26:57	0|adiabat|it'd be nicer to have it there instead of in an OP_RETURN
361 2016-06-08 19:26:57	0|rubensayshi|would that be better?
362 2016-06-08 19:27:17	0|luke-jr|adiabat: it's probably better in OP_RETURN tbh
363 2016-06-08 19:27:21	0|gmaxwell|adiabat: it's not under a signature there, so it can be stripped in relay, unfortunately.
364 2016-06-08 19:27:28	0|adiabat|yeah...
365 2016-06-08 19:27:37	0|gmaxwell|There is no good place to store arbritary data, unfortunately.
366 2016-06-08 19:27:48	0|adiabat|you'd have to put like a hash of it in the output script, then put your 520 byte preimage in the witness
367 2016-06-08 19:27:51	0|rubensayshi|op_drop?
368 2016-06-08 19:27:55	0|luke-jr|gmaxwell: Factom! :P
369 2016-06-08 19:27:58	0|adiabat|heh
370 2016-06-08 19:28:05	0|gmaxwell|except via a _commitment_ in op_return and the data elsewhere, which was already whas op_return as standard was supposted to be.
371 2016-06-08 19:28:08	0|adiabat|op_2drop is even more efficient :)
372 2016-06-08 19:28:41	0|rubensayshi|if all my addresses would be P2SH I could put it in the scriptSig with an op_drop no?
373 2016-06-08 19:28:53	0|gmaxwell|The problem with op_return is that the data still ends up in prued-nowit-sync and in SPV scans.  The problem with putting it in the witness is that it's not signed.
374 2016-06-08 19:29:08	0|gmaxwell|rubensayshi: sure you can, but any joker can strip it out of the transactions as they go past.
375 2016-06-08 19:29:09	0|adiabat|at some point someone should make like a p2pool backed merkle-branch-service
376 2016-06-08 19:29:23	0|rubensayshi|ah right
377 2016-06-08 19:30:06	0|adiabat|~most of the data on the segnet4 blockchain is op_2drop witness items
378 2016-06-08 19:30:12	0|adiabat|nobody modified any of them :)
379 2016-06-08 19:30:58	0|gmaxwell|I think we should add some 'notes' facility, where people can publish data into a DHT(spit) with access rate limited by ownership of stationary txouts.  Then if they want commitments in op-returns great. We'd hoped people would build this for themselves, but building complex infrastructure isn't something many people do when there is a speculative asset they could be pumping instead.
380 2016-06-08 19:31:15	0|gmaxwell|adiabat: thats been done, it was called chronobit.
381 2016-06-08 19:31:37	0|gmaxwell|adiabat: yea, sure lots of things work for a while. :)
382 2016-06-08 19:31:43	0|adiabat|huh!  look at that.  and people use op_return instead...
383 2016-06-08 19:31:49	0|luke-jr|gmaxwell: the hard part there is proving ownership
384 2016-06-08 19:32:13	0|gmaxwell|luke-jr: you just write a non-minable transaction to perform your insert.
385 2016-06-08 19:32:28	0|luke-jr|gmaxwell: that involves key reuse :<
386 2016-06-08 19:32:41	0|gmaxwell|adiabat: utter refusal to use anything except the simplest possible thing. "This is why we can't have nice things".
387 2016-06-08 19:32:48	0|gmaxwell|luke-jr: so? not in a way that matters.
388 2016-06-08 19:33:05	0|gmaxwell|Key reuse isn't inherently bad. Reusing in dumb ways is.
389 2016-06-08 19:33:34	0|gmaxwell|If your alternative was to transact; then signmessaging is stricly superior.
390 2016-06-08 19:33:40	0|adiabat|oh, semi-unrelated but, gmaxwell: remember the "bloom filter digest" post about a month ago on the mailing list
391 2016-06-08 19:33:43	0|luke-jr|there is zero risk of QC ever?
392 2016-06-08 19:33:54	0|adiabat|and you said, since you're not updating, there's better structures than bloom filters
393 2016-06-08 19:34:04	0|gmaxwell|luke-jr: it doesn't change anything wrt QC when your alternative was just transacting!
394 2016-06-08 19:34:26	0|luke-jr|transacting doesn't leave coins on the key ;)
395 2016-06-08 19:34:29	0|gmaxwell|adiabat: yes.
396 2016-06-08 19:34:54	0|adiabat|gmaxwell: Do you know if anyone's working on that, or a BIP or anything?  It looked like it was from a troll account...
397 2016-06-08 19:35:09	0|gmaxwell|I don't think anyone is working on it right now.
398 2016-06-08 19:35:13	0|adiabat|I don't really want to commit to like "I'll work on that" because I might not have time but...
399 2016-06-08 19:35:28	0|adiabat|it seems so much nicer than the current merkle block stuff
400 2016-06-08 19:35:37	0|gmaxwell|adiabat: well would be good for you to, and if other people show up I can point them at you.
401 2016-06-08 19:35:50	0|luke-jr|a better way IMO would be to use sign-to-contract to commit to another key, and use that key to sign the DHT publication
402 2016-06-08 19:36:00	0|gmaxwell|TBH, I'm a bit afraid to work on technology that I really like right now, because it'll just get attacked because I like it. :(
403 2016-06-08 19:36:27	0|AaronvanW|"Do you guys know what the the latest up to date spec for stealth addresses is?" (asking for someone... who is asking for me.)
404 2016-06-08 19:36:31	0|gmaxwell|luke-jr: but then access to publish is people who don't have bitcoins anymore which would be kinda odd. :)
405 2016-06-08 19:36:42	0|adiabat|gmaxwell: heh yeah... do you have any links to the more efficient filters, like the binomial codec you linked to?
406 2016-06-08 19:37:04	0|luke-jr|gmaxwell: contracthash then? :P
407 2016-06-08 19:38:07	0|gmaxwell|adiabat: well the more efficient filter is just like a bloom but with a single hash function and large number of candidate positions, and then you compress the result, using your choice of optimal compressor for cases where the probablity of a 1 is very low
408 2016-06-08 19:38:18	0|gmaxwell|luke-jr: doesn't achieve your goal.
409 2016-06-08 19:38:35	0|luke-jr|hm
410 2016-06-08 19:39:17	0|gmaxwell|I wish I never pointed out that the use of hashed keys might harden a little against QC, it's vastly overestimated in performance. If we think that is at all a threat we need to be urgently migrating to secure schemes.
411 2016-06-08 19:39:21	0|luke-jr|MAST with a branch for payment vs message vs DHT-message :P
412 2016-06-08 19:40:13	0|gmaxwell|adiabat: So, for example, a simple range coder would work. rice coding might be reasonably efficient, or things like the binomial codec I linked to.
413 2016-06-08 19:40:29	0|gmaxwell|luke-jr: cute.
414 2016-06-08 19:40:33	0|adiabat|gmaxwell: so maybe start with the current murmur hash, and look at different compression encodings?
415 2016-06-08 19:40:35	0|luke-jr|gmaxwell: I consider it a useful property in that it doesn't cause QCs to take all old coins not being spent immediately. It does that, at least, no?
416 2016-06-08 19:40:59	0|gmaxwell|adiabat: or siphash 1-3.     Yes, thats possible.
417 2016-06-08 19:41:46	0|gmaxwell|adiabat: another newly trendy kind of data structure for this is a cuckoo filter, though for ideal use here you'd also need to compress it, though the compression could be simpler.
418 2016-06-08 19:42:05	0|gmaxwell|it might work better simply because it will be smaller in memory when matching.
419 2016-06-08 19:42:19	0|adiabat|gmaxwell: OK thanks, will look into it.  Probably can't work on it much, but it doesn't *feel* that hard... in fact feels simpler than the current merkle-blocks and then send txs stuff
420 2016-06-08 19:42:45	0|gmaxwell|Yes, it's simpler. I think fully elaborated out you could go very deep down a rabbit hole, but the basic idea is simple.
421 2016-06-08 19:43:32	0|adiabat|gmaxwell: the main design tradeoff seems to be the size of the block digest.  Too small and lots of false positives and people have to download lots of blocks.  Too big and you're spending a lot of space on the digest.
422 2016-06-08 19:43:37	0|gmaxwell|A cool thing about it is that it could be used before being commited, so people could try many different designs and explore the solution space pretty far.
423 2016-06-08 19:44:05	0|adiabat|yeah, could implement it on the p2p layer without any consensus changes
424 2016-06-08 19:44:23	0|gmaxwell|well you can also do things like multiple tiers, like a digest covering groups of 8 blocks, and a digest covering single blocks.. even digests covering parts of blocks.
425 2016-06-08 19:44:24	0|adiabat|and the node could lie to you, but they can do that right now with bloom filters anyway
426 2016-06-08 19:45:19	0|adiabat|also feels like maybe a perverse incentive would be that you'd not want to make as many new addresses, as your false positive rate would go up and you'd have to download more...
427 2016-06-08 19:45:50	0|gmaxwell|the current system has that issue, these commited schemes have less of it.
428 2016-06-08 19:46:19	0|adiabat|yeah, basically nothing about it seems any *worse* than the current filter system
429 2016-06-08 19:47:05	0|gmaxwell|There are other totally different alternatives though, like PIR scan services, which I think we almost have enough in bitcoin core to support as a purely external add on.
430 2016-06-08 19:48:01	0|adiabat|PIR scans would be better but also seems more complex...
431 2016-06-08 19:48:50	0|adiabat|not that people shouldn't do it, but I feel like I could reasonably get a block digest to work, but getting a PIR system seems more .. innovative :)
432 2016-06-08 19:48:50	0|gmaxwell|much more complex, though a lot of the heavy lifting has been done by other people (percy++)
433 2016-06-08 19:49:07	0|gmaxwell|hah
434 2016-06-08 19:49:19	0|gmaxwell|I only bring it up in the hope that someone will be foolish enough to think it easy.
435 2016-06-08 19:49:48	0|gmaxwell|Though actually I think they're more similar in difficulty than you think... in both cases the details are what get you.
436 2016-06-08 19:50:20	0|adiabat|yeah, I guess with the digest, you can get something working even if the details are wrong and it works sub-optimally
437 2016-06-08 19:50:44	0|adiabat|with PIR, well... I guess you wouldn't really know if it was horribly broken and revealed everything that you were requesting
438 2016-06-08 19:51:52	0|gmaxwell|PIR is straight forward: there is existing software that lets you have a {key, value} database and query it privately.  Take the existing utxo set, order by address, for every txout for each address, generate a txout proof (gettxoutproof rpc), for it. ... now thats your database.  People query it with each of there addresses, and import the results into the wallet after verifying the proofs. Tad
439 2016-06-08 19:52:05	0|gmaxwell|a.
440 2016-06-08 19:53:08	0|gmaxwell|The reality is less simple, because different addresses have (vastly) different numbers of txouts connected with them.. so you have to have some way of handling it.
441 2016-06-08 19:54:23	0|gmaxwell|and maybe the inefficiency of all that makes it unreasonable to use.
442 2016-06-08 19:54:23	0|gmaxwell|Probably the thing to do is take all the txouts for each address and make the keys  key, key_2, key_3, key_4... for each of them.  and have the first key tell you how many txouts there are in total.
443 2016-06-08 19:54:23	0|gmaxwell|Though that still will have some inefficiency since the txoutproof has the whole transaction paying you in it, so they'd all need to be padded up to a constant (large size).
444 2016-06-08 19:55:06	0|adiabat|yeah... also percy++ looks a little scary to work with in that I don't think there's a lot of real world implementations using it right now
445 2016-06-08 19:56:25	0|adiabat|wheras the block digest idea just jumps out as like "Oh yeah that'll work!"
446 2016-06-08 19:56:28	0|gmaxwell|Right.  Well most people have no desire,  "keep user data private? but then how will we sell it?" :)  a positive point is that the academics working on it are actually competent programmers too (not always the case)... so I think it's likely to not be a software engineering disaster (and it's always worked right when I've messed around with it)
447 2016-06-08 19:57:10	0|adiabat|yeah I looked at percy++ a year or two ago and it does seem to be well made
448 2016-06-08 19:57:18	0|gmaxwell|adiabat: indeed, it will, though less private!  it's also not exclusive with using PIR.. a simpler way to use PIR would be to use it to fetch the whole blocks you're going to fetch.
449 2016-06-08 19:58:28	0|adiabat|I guess I'm also not just looking at it from a privacy perspective, though that's a big part of it
450 2016-06-08 19:58:41	0|gmaxwell|::nods::
451 2016-06-08 19:58:46	0|adiabat|with LN channels, a false negative can be a big problem
452 2016-06-08 19:58:51	0|gmaxwell|the existing bloom stuff is just broken on a bunch of levels.
453 2016-06-08 19:59:29	0|adiabat|yeah, if the node you're asking to filter for you omits the tx where someone closes a channel incorrectly, you might not know and lose coins
454 2016-06-08 19:59:41	0|gmaxwell|it's vulnerable to attack both from data hiding and from denial of service, its resource intensive, .. strongly discourages  single use addresses.. quite non-private...
455 2016-06-08 19:59:59	0|adiabat|oh and the merkle-block data structure is... weird...
456 2016-06-08 20:00:08	0|adiabat|and then it sends the txs, unrequested
457 2016-06-08 20:00:57	0|_anthony_|bitcoin satellites are definitely the way to go
458 2016-06-08 20:01:08	0|gmaxwell|yea, a side effect of the bitcoin protocol having no mechensim to just fetch txn already in blocks, which has a good reason for it (among other things, it helps keep the network from being abused as a file trading DHT)
459 2016-06-08 20:01:39	0|gmaxwell|BIP152 actually adds a sutiable mechenism-- getblocktxn that fetches txn in a block by index, that only works for recent blocks.
460 2016-06-08 20:11:33	0|sipa|my train internet connection is too weak to actually visit github.com, but can someone see if https://github.com/sipa/bitcoin/commits/dogcgit renerders nicely?
461 2016-06-08 20:15:23	0|gmaxwell|sipa: 404.
462 2016-06-08 20:15:41	0|paveljanik|sipa, yes, looks nice - https://github.com/bitcoin/bitcoin/compare/master...sipa:docgit
463 2016-06-08 20:15:59	0|gmaxwell|https://github.com/sipa/bitcoin/commits/docgit maybe
464 2016-06-08 20:20:29	0|sipa|yes indeed; thanks!
465 2016-06-08 20:21:46	0|GitHub146|[13bitcoin] 15kazcw opened pull request #8177: developer notes: deprecate C-style casts (06master...06no-c-casts) 02https://github.com/bitcoin/bitcoin/pull/8177
466 2016-06-08 21:42:03	0|luke-jr|can someone reopen https://github.com/bitcoin/bitcoin/pull/5872 so I can push to it (addressing unreviewability concerns)?
467 2016-06-08 22:32:01	0|frankenmint|heh, rusty russel also invented modprobe
468 2016-06-08 22:32:35	0|gmaxwell|Someday we'll forgive him.
469 2016-06-08 22:41:28	0|luke-jr|XD
470 2016-06-08 22:41:32	0|sipa|and if not, we'll xkcd538 him with a 5 AUD rusty wrench
471 2016-06-08 22:41:45	0|luke-jr|sipa: ^ 1 hr ago
472 2016-06-08 22:42:34	0|GitHub126|[13bitcoin] 15sipa reopened pull request #5872: configure: BITCOIN_SUBDIR_TO_INCLUDE: Improve compatibility with paths including space and multiline cpp output (06master...06subdir_incl_compat) 02https://github.com/bitcoin/bitcoin/pull/5872
473 2016-06-08 22:42:38	0|luke-jr|thx
474 2016-06-08 22:44:58	0|luke-jr|hopefully that's finally reviewable
475 2016-06-08 22:51:56	0|sipa|luke-jr: i'm not sure i understand the problem it os trying to address
476 2016-06-08 22:52:00	0|sipa|you say it is biggy
477 2016-06-08 22:52:08	0|sipa|how does that manifest?
478 2016-06-08 22:53:57	0|luke-jr|sipa: I think mostly paths with spaces failing
479 2016-06-08 22:54:24	0|sipa|ah
480 2016-06-08 23:06:49	0|GitHub106|[13bitcoin] 15sipa opened pull request #8178: Add git and github tips and tricks to developer notes (06master...06docgit) 02https://github.com/bitcoin/bitcoin/pull/8178
481 2016-06-08 23:16:41	0|btcdrak|sipa: more gitfu please