1 2018-03-16 00:00:36	0|promag|sipa: I was reading that one, are you going to remove the remaining REF usages?
  2 2018-03-16 00:01:41	0|sipa|promag: i'm going to remove all casts from the serialization code, see #10785
  3 2018-03-16 00:01:44	0|gribble|https://github.com/bitcoin/bitcoin/issues/10785 | Serialization improvements by sipa · Pull Request #10785 · bitcoin/bitcoin · GitHub
  4 2018-03-16 00:16:43	0|kallewoof|I'm a little confused by luke-jr's comment on {sign/verify}message replacement thread. He is saying not specific UTXO's but prove that funds are available. How would you do that, if you didn't sign for specific UTXO's?
  5 2018-03-16 00:17:18	0|kallewoof|Basically, he wants to be able to prove that funds are available using a signature, since that's often what people do with signmessage today.
  6 2018-03-16 00:51:29	0|bitcoin-git|[13bitcoin] 15kallewoof opened pull request #12701: [wallet] importprivkey: explicit rescan for known key (06master...06importprivkey-explicit-rescan) 02https://github.com/bitcoin/bitcoin/pull/12701
  7 2018-03-16 00:59:34	0|bitcoin-git|[13bitcoin] 15kallewoof opened pull request #12702: [wallet] [rpc] [doc] importprivkey: hint about importmulti (06master...06importprivkey-importmulti-hint) 02https://github.com/bitcoin/bitcoin/pull/12702
  8 2018-03-16 01:01:45	0|bitcoin-git|[13bitcoin] 15kallewoof closed pull request #12701: [wallet] importprivkey: explicit rescan for known key (06master...06importprivkey-explicit-rescan) 02https://github.com/bitcoin/bitcoin/pull/12701
  9 2018-03-16 01:02:34	0|promag|kallewoof: IMO all RPC that are a subset of importmulti should be deprecated
 10 2018-03-16 01:02:48	0|sipa|well not right now
 11 2018-03-16 01:02:57	0|sipa|importmulti can't deal with P2SH-P2WPKH addresses yet
 12 2018-03-16 01:03:15	0|promag|sipa maybe never (so it doesn't break anything)
 13 2018-03-16 01:03:22	0|sipa|?
 14 2018-03-16 01:04:02	0|promag|I mean, existing software would have to change if we deprecated those calls
 15 2018-03-16 01:04:17	0|sipa|deprecating doesn't mean removing
 16 2018-03-16 01:04:29	0|promag|sipa: means it will be removed
 17 2018-03-16 01:04:33	0|promag|no?
 18 2018-03-16 01:04:40	0|promag|eventually.. :P
 19 2018-03-16 01:04:42	0|sipa|yes, at some point in the future
 20 2018-03-16 01:04:43	0|sipa|exactly
 21 2018-03-16 01:04:56	0|sipa|we're deprecating and removing things all the time
 22 2018-03-16 01:05:47	0|promag|anyway, IMO the note should be "use importmulti instead, even for 1 entry"
 23 2018-03-16 01:06:13	0|kallewoof|promag: I'm fine with that, but sipa noted that there are cases where you cannot use importmulti.
 24 2018-03-16 01:06:41	0|kallewoof|promag: So I'm keeping it as is. To be updated once P2SH-P2WPKH support is added to importmulti.
 25 2018-03-16 01:06:41	0|sipa|well we should fix that :)
 26 2018-03-16 01:07:12	0|kallewoof|sipa: Yeah that would be ideal, I suppose
 27 2018-03-16 01:07:56	0|promag|is there a plan for that sipa?
 28 2018-03-16 01:08:09	0|sipa|I hereby instate such a plan.
 29 2018-03-16 01:08:42	0|sipa|(it's listed as a future TODO in #11403
 30 2018-03-16 01:08:45	0|gribble|https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
 31 2018-03-16 01:14:37	0|kallewoof|Weird that the importmulti says `"rescan": <false>   (boolean, optional, default: true)`. Sending mixed signals there lol...
 32 2018-03-16 01:15:06	0|sipa|lol
 33 2018-03-16 01:15:09	0|sipa|that should be fixed
 34 2018-03-16 01:15:28	0|kallewoof|Yeah, it's no biggie, but it had me scratching my head for a sec.
 35 2018-03-16 01:17:10	0|kallewoof|Also feels like "scriptPubKey": "<script>" | { "address":"<address>" } could just be... "scriptPubKey" : "<script or address>" since I don't think there's ever a case where you would confuse an addy for a script or vice versa.
 36 2018-03-16 01:17:40	0|kallewoof|Or rather, you can always determine which it is, I think.
 37 2018-03-16 01:17:42	0|sipa|the design makes things intentionally explicit
 38 2018-03-16 01:17:58	0|sipa|to minimize risk for having the RPC doing something other than what you intend
 39 2018-03-16 01:18:10	0|sipa|you also have to explicitly say you want something as watch only etc
 40 2018-03-16 01:18:26	0|kallewoof|sipa: Gotcha. Yeah, that makes sense.
 41 2018-03-16 01:18:39	0|sipa|it's certainly not the easiest thing to use as a human
 42 2018-03-16 01:18:47	0|sipa|but for programmatic access, none of these things matter
 43 2018-03-16 01:19:22	0|kallewoof|*nod*
 44 2018-03-16 01:20:46	0|promag|+1
 45 2018-03-16 01:21:31	0|promag|it doesn't try to guess, but it validates the input
 46 2018-03-16 01:22:16	0|promag|out of battery o/
 47 2018-03-16 02:11:35	0|jimpo|quit
 48 2018-03-16 02:11:48	0|jimpo|:facepalm:
 49 2018-03-16 02:13:17	0|sipa|hah
 50 2018-03-16 02:14:21	0|sipa|jimpo: i just had a look at bip157/158; do you think it's really necessary that the extended filter is mandatory for the p2p protocol?
 51 2018-03-16 02:15:07	0|jimpo|There was some discussion about how to do support for multiple filter types
 52 2018-03-16 02:15:30	0|jimpo|the first draft had a getcftypes/cftypes message pair where a client could query a node's supported filters
 53 2018-03-16 02:16:13	0|jimpo|but BlueMatt pointed out that it is something you want to filter nodes for before connecting (ie. exposed through addr advertisements)
 54 2018-03-16 02:16:29	0|sipa|i guess i mostly don't understand why the extended filter is useful
 55 2018-03-16 02:16:36	0|jimpo|so that was dropped and the service bit mandates nodes support all currently defined types
 56 2018-03-16 02:17:06	0|sipa|so it seems like a waste of space
 57 2018-03-16 02:18:44	0|sipa|but maybe i'm just missing the use case
 58 2018-03-16 02:18:48	0|jimpo|hmm, I can't remember the reason right now. roasbeef would know.
 59 2018-03-16 02:19:24	0|sipa|also, are there some numbers for how large the fikters typically are?
 60 2018-03-16 02:19:46	0|jimpo|I'm collecting that data right now actually
 61 2018-03-16 02:19:49	0|sipa|cool
 62 2018-03-16 02:20:11	0|sipa|ideally it should be some small multiple of 20 bits per element, i expect.
 63 2018-03-16 02:21:46	0|jimpo|right, the question is how many elements are expected per tx and how big they are compared to 20 bits
 64 2018-03-16 02:21:57	0|jimpo|I should have an answer shortly
 65 2018-03-16 02:22:13	0|jimpo|Thx for taking a look at the BIPs
 66 2018-03-16 02:24:43	0|sipa|i also suggested before that it may be better to index just the entire scriptPubKey rather than individual pushes in it (every realistic output type these days has just one push, so for practical things it's the same, and has less risk for someone filling up the filter with many tiny pushes)
 67 2018-03-16 02:25:00	0|sipa|but maybe that's a bit late to change (or there is another reason i'm missing)
 68 2018-03-16 02:26:57	0|jimpo|Regarding the extended filter, it sounds like there aren't concrete applications right now, but it's for more complex contracting applications
 69 2018-03-16 02:27:19	0|jimpo|So for example, in a world with MAST, you might want to find all txs with a particular script redeem clause
 70 2018-03-16 02:27:30	0|sipa|mhmm
 71 2018-03-16 02:27:55	0|sipa|in a world with signature aggregation there may not be anything to match o
 72 2018-03-16 02:28:08	0|sipa|i'm not convinced that's useful in the long term
 73 2018-03-16 02:28:31	0|jimpo|with sig aggregation aren't all of the pubkeys published?
 74 2018-03-16 02:28:32	0|sipa|and in general, when there is, that in itself is sort of a sign that we're regealing too much information
 75 2018-03-16 02:28:40	0|sipa|*key aggregation
 76 2018-03-16 02:28:49	0|jimpo|I guess I'm not up to date on whether you are planning on using MuSig or Bellare-Neven
 77 2018-03-16 02:29:01	0|sipa|BN, but this is orthogonal
 78 2018-03-16 02:29:15	0|jimpo|With BN, individual pubkeys are published, right?
 79 2018-03-16 02:29:29	0|sipa|yes, but there would generally just be one per output
 80 2018-03-16 02:29:41	0|sipa|BN is used across the inputs of a tx
 81 2018-03-16 02:29:43	0|jimpo|and regardless of key/sig aggregation, the use case of scanning for MAST redeem clauses still stands
 82 2018-03-16 02:29:54	0|jimpo|no?
 83 2018-03-16 02:30:07	0|sipa|ideally there would not be something to match on
 84 2018-03-16 02:30:45	0|sipa|i do say ideally here - i see how it could be useful
 85 2018-03-16 02:30:54	0|jimpo|he's something concrete:
 86 2018-03-16 02:31:06	0|sipa|but in general we should aim for systems where all outputs and inouts are indistinguishable
 87 2018-03-16 02:31:33	0|sipa|so the only thing to match on would be an exact output script, or an input (based on outpoint) spending iy
 88 2018-03-16 02:31:34	0|jimpo|say lightning contracts are implemented with MAST and you want to find the ones that are redeemed with a particular hash preimage (for some reason)
 89 2018-03-16 02:31:49	0|sipa|sure, for now
 90 2018-03-16 02:32:12	0|sipa|longer term i think we want to avoid having hash preimages?
 91 2018-03-16 02:32:35	0|sipa|i'm probably thinking further
 92 2018-03-16 02:36:14	0|jimpo|Perhaps
 93 2018-03-16 02:36:35	0|sipa|i'm just a bit hesitant about committing to building a filter that only has uncertain use cases now, and is really only usable in situationd that are already undesirable
 94 2018-03-16 02:36:47	0|jimpo|Ultimately, this becomes philosophical: do we want to have more options to be future-proof or only support uses cases that we can think of today
 95 2018-03-16 02:37:06	0|sipa|hmm, i think it's the other way around
 96 2018-03-16 02:37:13	0|sipa|adding a filter is easy if necessary
 97 2018-03-16 02:37:20	0|jimpo|I don't have a strong preference as long as the basic filter is in
 98 2018-03-16 02:37:32	0|sipa|removing one is hard, if there is an ecosystem that unnecessarily relies on ot
 99 2018-03-16 02:37:40	0|sipa|*on it
100 2018-03-16 02:38:07	0|sipa|anyway, thanks for discussing it
101 2018-03-16 02:38:16	0|sipa|and i'm looking forward to seeing some numbers
102 2018-03-16 05:56:23	0|bitcoin-git|[13bitcoin] 15bitkevin opened pull request #12704: base58: use map instead of strchr() when decode (06master...06b58_bitmap) 02https://github.com/bitcoin/bitcoin/pull/12704
103 2018-03-16 07:40:14	0|bitcoin-git|[13bitcoin] 15kallewoof opened pull request #12705: Importmulti private key support (06master...06importmulti-wif-support) 02https://github.com/bitcoin/bitcoin/pull/12705
104 2018-03-16 08:05:29	0|stevenroose|Is there a limit on the number of outputs in a tx?
105 2018-03-16 08:05:58	0|stevenroose|it's just uint32, I guess? so no
106 2018-03-16 08:45:36	0|pyericz|the more outputs in a tx, the more fees you have to pay
107 2018-03-16 09:00:56	0|eklitzke|good luck fitting (1<<32) tx in a singe block
108 2018-03-16 09:06:01	0|kallewoof|output, not tx, but yeah... 0.0002328306 bytes per output (excluding other tx content). need some rad compression to pull that off.
109 2018-03-16 10:06:13	0|karelb|Where do translations lie in bitcoin core source code?
110 2018-03-16 10:07:03	0|karelb|https://github.com/bitcoin/bitcoin/tree/master/src/qt/locale
111 2018-03-16 10:07:03	0|karelb|Oh, here?
112 2018-03-16 10:09:10	0|karelb|@spudowiar (not here now) had an idea - that it would be good to separate RPC documentation from the code, so things like https://github.com/bitcoin-core/bitcoincore.org/pull/526 could be generated (and fixed) more easily. I was thinking which format is best
113 2018-03-16 10:12:30	0|karelb|since once you separate it into a format, you need to parse that :) if it isn't a C code
114 2018-03-16 11:35:40	0|rex_4539|karelb Translations are in https://www.transifex.com/bitcoin
115 2018-03-16 13:41:36	0|ossifrage|Has anyone shone interest in changing outbound rate limit works from a bytes/time interval to something a bit smoother?
116 2018-03-16 13:42:29	0|ossifrage|I added the ability to specify the nMaxOutboundLimit on the command line and I use a 1 hour limit vs the default of 24hrs
117 2018-03-16 13:45:00	0|ossifrage|But I still get these spikes where bitcoind will saturate my gbit connection until it consumes the 1 hour limit
118 2018-03-16 13:45:47	0|ossifrage|I could rate limit at the firewall, but I don't want to slow down normal usage, just serving old blocks
119 2018-03-16 14:39:25	0|hkjn0|hm, when building on armv7l, I a) build depends, b) do ./configure with --prefix set to depends/<arch>, c) make, this works fine, but unexpectedly leads 'make install' to put bins and libs in that prefix
120 2018-03-16 14:39:45	0|hkjn0|i.e instead of bitcoind being installed in /usr/local/bin, I get: 'libtool: install: /usr/bin/install -c bitcoind /usr/local/src/bitcoin/depends/armv7l-unknown-linux-gnueabihf/bin/bitcoind'
121 2018-03-16 14:42:09	0|hkjn0|I found https://cmake.org/cmake/help/v3.0/variable/CMAKE_INSTALL_PREFIX.html which looked promising, but doesn't quite do it: 'libtool: install: /usr/bin/install -c bitcoind /usr/local/bin/usr/local/src/bitcoin/depends/armv7l-unknown-linux-gnueabihf/bin/bitcoind'
122 2018-03-16 15:12:20	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #12707: log: Be less confusing in the way we inform the user that logging has started (06master...06scrolling-can-be-fun-but-this-is-too-much-fun) 02https://github.com/bitcoin/bitcoin/pull/12707
123 2018-03-16 16:37:12	0|Guest39|ping
124 2018-03-16 17:25:38	0|arubi|hkjn0, you need to use --exec-prefix to set the install directory
125 2018-03-16 17:28:55	0|bitcoin-git|[13bitcoin] 15sipa opened pull request #12708: Make verify-commits.sh test that merges are clean (06master...06201803_cleanmerge) 02https://github.com/bitcoin/bitcoin/pull/12708
126 2018-03-16 17:46:53	0|hkjn0|arubi: oh, so ./configure with both --prefix and --exec-prefix? thanks, will give it a try
127 2018-03-16 18:36:25	0|bitcoin-git|[13bitcoin] 15instagibbs opened pull request #12709: shuffle sendmany recipients ordering, since caller cannot control (06master...06shuffleoutputs) 02https://github.com/bitcoin/bitcoin/pull/12709
128 2018-03-16 20:19:22	0|provoostenator|Alright, I went through the list of open Github tickets today. Hopefully helped a few get closed soon, but I may also have awakened a dragon or two.
129 2018-03-16 20:32:01	0|jimpo|That's epic, provoostenator. Thanks!
130 2018-03-16 22:04:49	0|Randolf|provoostenator:  Dragons waking up now?  Excellent, for cryptocurrencies need more dragons to scare the troublemakers away.  :)
131 2018-03-16 23:59:54	0|bitcoin-git|13bitcoin/06master 147ef46d0 15practicalswift: Remove redundant includes. Conform to header include guidelines....
132 2018-03-16 23:59:54	0|bitcoin-git|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/7be9a9a570c1...af20f9b1d485
133 2018-03-16 23:59:55	0|bitcoin-git|13bitcoin/06master 14af20f9b 15Pieter Wuille: Merge #12542: Remove redundant includes. Conform to header include guidelines....