1 2018-09-12T00:28:12  *** harrymm has quit IRC
  2 2018-09-12T00:32:13  *** echonaut has quit IRC
  3 2018-09-12T00:32:30  *** echonaut has joined #bitcoin-core-dev
  4 2018-09-12T00:34:34  *** miknotauro has joined #bitcoin-core-dev
  5 2018-09-12T00:37:42  *** molz has joined #bitcoin-core-dev
  6 2018-09-12T00:41:19  *** harrymm has joined #bitcoin-core-dev
  7 2018-09-12T00:46:35  *** molz has quit IRC
  8 2018-09-12T00:49:52  *** molz has joined #bitcoin-core-dev
  9 2018-09-12T00:55:49  *** molz has quit IRC
 10 2018-09-12T01:01:32  *** molz has joined #bitcoin-core-dev
 11 2018-09-12T01:06:03  *** molz has quit IRC
 12 2018-09-12T01:07:37  *** Cory has quit IRC
 13 2018-09-12T01:14:40  *** Cory has joined #bitcoin-core-dev
 14 2018-09-12T01:19:10  *** Victorsueca has quit IRC
 15 2018-09-12T01:20:24  *** Victorsueca has joined #bitcoin-core-dev
 16 2018-09-12T01:22:19  *** sipa_ has joined #bitcoin-core-dev
 17 2018-09-12T01:25:03  *** sipa has quit IRC
 18 2018-09-12T01:33:45  *** molz has joined #bitcoin-core-dev
 19 2018-09-12T01:35:03  *** Chris_Stewart_5 has quit IRC
 20 2018-09-12T01:57:52  *** unholymachine has quit IRC
 21 2018-09-12T01:58:17  *** unholymachine has joined #bitcoin-core-dev
 22 2018-09-12T02:00:30  *** unholymachine has quit IRC
 23 2018-09-12T03:05:19  *** GoldenBear has quit IRC
 24 2018-09-12T03:16:59  *** GoldenBear has joined #bitcoin-core-dev
 25 2018-09-12T03:21:54  *** qrestlove has quit IRC
 26 2018-09-12T03:26:55  <moneyball> dongcarl your topic mentioned earlier today has been added to the CoreDev list
 27 2018-09-12T03:27:21  *** qrestlove has joined #bitcoin-core-dev
 28 2018-09-12T03:30:33  <gmaxwell> Decreasing the number of people who can review the software by five orders of magnitude doesn't sound like a particularly strong way to achieve a security improvement.
 29 2018-09-12T03:32:07  <gmaxwell> in particular because modern-ish C++ is a lot safer 'by default' than C code... and a lot of the constructs that you need to use in rust to get acceptable performance, like iterators, are also safe in C++.  Not that I dislike rust, but overhype is bad for everyone.
 30 2018-09-12T03:33:15  *** Krellan has quit IRC
 31 2018-09-12T04:08:06  *** Victorsueca has quit IRC
 32 2018-09-12T04:09:20  *** Victorsueca has joined #bitcoin-core-dev
 33 2018-09-12T04:27:02  *** jarthur has joined #bitcoin-core-dev
 34 2018-09-12T04:53:12  <kallewoof> I'm honestly confused what this guy is concerned about: https://twitter.com/DrRoyMurphy/status/1039512043567497221 He calls glaring problems about a sign/verifymessage proposal, then talks about wallet security, unescaped loop injection (?), and then goes on an opcode rant.
 35 2018-09-12T04:54:21  <kallewoof> Is he talking about Johnson Lau's OP_MESSAGE comment, maybe..?
 36 2018-09-12T04:57:46  <luke-jr> kallewoof: IIRC, that's a CSW troll pretending to be an "early dev"; likely has no idea what he's talking about, just trying to sound smart
 37 2018-09-12T04:58:46  <kallewoof> luke-jr: Okay...
 38 2018-09-12T04:59:11  <luke-jr> if you try to get a sensible explanation out of him, he'll probably end up blocking you :P
 39 2018-09-12T04:59:15  <kallewoof> Unescaped loop injection. What on earth is that anyway?
 40 2018-09-12T04:59:33  <kallewoof> luke-jr: I don't care about being blocked, tbh. I guess I'll just ask him about it.
 41 2018-09-12T05:11:47  *** miknotauro has quit IRC
 42 2018-09-12T05:23:20  *** drexl has quit IRC
 43 2018-09-12T05:23:51  *** jarthur has quit IRC
 44 2018-09-12T05:30:48  <gmaxwell> kallewoof: guy appears to just be a drug addict nutcase from prior discussions I saw from him.
 45 2018-09-12T05:32:26  <kallewoof> gmaxwell: at least he knows how to make someone feel insecure about themselves. i still have no clue what an unescaped loop injection is.
 46 2018-09-12T05:33:40  <gmaxwell> kallewoof: nor does he.
 47 2018-09-12T05:34:21  <gmaxwell> If no one does, then he can't be wrong. Checkmate Engineers.
 48 2018-09-12T05:35:22  <sipa_> kallewoof: the proper response is muting him
 49 2018-09-12T05:37:17  <kallewoof> I guess I'll see what his response is and if that makes no sense either I'll just mute and move on
 50 2018-09-12T05:38:00  <gmaxwell> just don't let him keep you going by changing the subject.
 51 2018-09-12T05:38:14  <sipa_> kallewoof: no, mute him, nos
 52 2018-09-12T05:38:21  <sipa_> there is nothing useful he says
 53 2018-09-12T05:38:28  <gmaxwell> lol
 54 2018-09-12T05:38:33  <sipa_> all his claims are total garbage bullshit
 55 2018-09-12T05:38:49  <gmaxwell> in any case, he came up before, he's some bitconnect promoter that claims the be one of the first bitcoin developers after satoshi and a bunch of other stuff that made no sense.
 56 2018-09-12T05:39:01  <kallewoof> ahh... okay.
 57 2018-09-12T05:39:32  <gmaxwell> https://twitter.com/DrRoyMurphy/status/1030266403046260736
 58 2018-09-12T05:39:44  <gmaxwell> (where pieter made a mistake in talking to him)
 59 2018-09-12T05:41:44  <kallewoof> Ahh... Yeah looks like he is just a slimy clueless person. How quaint..
 60 2018-09-12T05:54:19  *** grubles has joined #bitcoin-core-dev
 61 2018-09-12T05:59:18  <kallewoof> Johnson Lau is suggesting reserving OP_MESSAGEONLY = 0xf0 as opcode for message signing, or alternatively "OP_RETURN msgXXX". It feels wasteful to take an opcode, but feedback would be nice: https://github.com/bitcoin/bips/pull/725#issuecomment-420421058
 62 2018-09-12T05:59:43  <kallewoof> The OP_RETURN thing seems like it could be a bit of a pain to implement for verifiers.
 63 2018-09-12T06:00:36  <kallewoof> Also still looks like 50/50 'want actual transaction format' vs 'do not want  actual transaction format'.
 64 2018-09-12T06:03:24  <echeveria> I'm not sure why you'd want that.
 65 2018-09-12T06:04:51  <echeveria> using RETURN seems kind of nasty too, as there's probably actually scripts in a lot of forms people would be signing.
 66 2018-09-12T06:04:57  <kallewoof> echeveria: It lets you use existing HSMs to sign messages, proofs of funds, etc. Apparently some HSMs are specifically built to never be updated, but it would be handy to be able to create proofs with them.
 67 2018-09-12T06:05:53  <echeveria> kallewoof: the exchange I'm aware of with that issue has others that mean they need to replace their hardware anyway.
 68 2018-09-12T06:06:10  <echeveria> kallewoof: only uncompressed point keys makes it sort of sucky to use for anything non-joke.
 69 2018-09-12T06:07:28  <kallewoof> echeveria: To quote argument for a tx-like protocol: "It also works well with proof of reserve: the proof of reserve is a bitcoin transaction spending all the funds, but with an additional input (covered by SIGHASH_ALL) that points to a fake/invalid tx. This has the additional benefit of working in a forward compatible way with any future bitcoin extension, like confidential transactions or mimblewimble: your proof of
 70 2018-09-12T06:07:28  <kallewoof> reserve could have blinded inputs and outputs as well, or whatever else the bitcoin protocol is made to allow. As long as the spends are tangled up with the fake input (via SIGHASH_ALL or a mimblewimble kernel, or whatever), it doesn't matter."
 71 2018-09-12T06:08:16  <echeveria> that sounds like it's attracting foot gunning, honestly.
 72 2018-09-12T06:08:31  <kallewoof> Sounds a bit dangerous, yeah.
 73 2018-09-12T06:11:44  *** Krellan has joined #bitcoin-core-dev
 74 2018-09-12T06:12:45  *** Krellan has joined #bitcoin-core-dev
 75 2018-09-12T06:12:55  <echeveria> that sort of cute thing really doesn't sit well with me. it's where I've seen people make really expensive mistakes in the past.
 76 2018-09-12T06:18:34  <aj> kallewoof: the backwards compatibility thing seems like the difference between "i trust the code handing stuff off to my hsm, but can't upgrade my hsm" vs "my hsm is an essential line of defense, i don't trust anything else"
 77 2018-09-12T06:19:16  <echeveria> aj: agreed entirely.
 78 2018-09-12T06:22:47  <kallewoof> aj: That's a good way of putting it
 79 2018-09-12T06:23:05  <aj> kallewoof: i wonder if adding an input txid=00..00,n=0,value=21e14 would be an interesting invalidator?
 80 2018-09-12T06:25:16  <kallewoof> aj: i don't know if it's really necessary. btw, i assumed from your comment that you were against the idea of a transaction based protocol, but now i'm unsure.
 81 2018-09-12T06:26:05  <aj> kallewoof: i'm still trying to form an opinion :)
 82 2018-09-12T06:26:20  <kallewoof> Ahh, okay
 83 2018-09-12T06:27:16  <aj> kallewoof: the thing i don't quite get... suppose you come up with a non-tx based thing, it's perfect, great, everyone puts it on their roadmap. but maaku or someone says no, here's a tx based plan that's compatible with existing signing hw, and posts a bip and sample implementation that works with trezors or whatever
 84 2018-09-12T06:27:18  <kallewoof> I've been going back and forth on the subject several times already. It seriously seems like everyone's opinion is split down the middle
 85 2018-09-12T06:28:01  <aj> kallewoof: all the people who say "my hsm is an essential line of defense" still have to be able to not accidently sign stuff via maaku's hypothetical method in that case, your avoidance of a tx based format doesn't save them any effort?
 86 2018-09-12T06:28:55  <echeveria> aj: the assumption seems to be kind of strange. they're using a HSM that supposedly has some more rules than "sign what comes to me", right?
 87 2018-09-12T06:29:20  <echeveria> if it's a dumb interface that signs anything hat comes to it, sounds like a shitty HSM.
 88 2018-09-12T06:29:32  <aj> echeveria: it could be one with an embedded ruleset, or it could be one with a display that lets you check the amt/address and say yes/no out of band
 89 2018-09-12T06:30:03  <echeveria> for the former, I'm not sure this hack would work a lot of the time anyway.
 90 2018-09-12T06:31:06  <luke-jr> it would be nice if it was such that scripts could have a different execution path for messages
 91 2018-09-12T06:31:18  <aj> luke-jr: why??
 92 2018-09-12T06:31:38  <echeveria> ?
 93 2018-09-12T06:32:00  <kallewoof> I think that's what Johnson Lau wants with the OP_MESSAGEONLY opcode?
 94 2018-09-12T06:32:09  <aj> luke-jr: jl2012's OP_MESSAGEONLY or OP_RETURN special handlying does that, but i don't get why
 95 2018-09-12T06:32:25  *** Victorsueca has quit IRC
 96 2018-09-12T06:32:29  <kallewoof> "OP_IF OP_MESSAGEONLY <key_m> OP_ELSE <key_s> OP_ENDIF OP_CHECKSIG"
 97 2018-09-12T06:32:39  <kallewoof> (https://github.com/bitcoin/bips/pull/725#issuecomment-420421058)
 98 2018-09-12T06:32:40  <luke-jr> aj: so you can sign with a key that can't spend
 99 2018-09-12T06:32:55  <echeveria> lol no
100 2018-09-12T06:33:21  <luke-jr> aj: and thereby avoid multiple signatures with the same key
101 2018-09-12T06:33:42  *** Victorsueca has joined #bitcoin-core-dev
102 2018-09-12T06:34:05  <aj> luke-jr: wouldn't you be better of signing with K+y*G in that case? otherwise that you know key_m doesn't really prove you know key_s
103 2018-09-12T06:34:33  <kallewoof> key_m would be signing that you know key_s, though
104 2018-09-12T06:34:44  <aj> kallewoof: claiming, but not proving
105 2018-09-12T06:34:48  <luke-jr> aj: you might not want to disclose the spending pubkey
106 2018-09-12T06:35:41  <luke-jr> if the messageonly path just had a hash of another script, it would save on-chain space; but maybe that can just wait for MAST
107 2018-09-12T06:36:54  <luke-jr> aj: I can't think of a reason to require messages prove ability to spend directly; that's already not the case for current signed messages
108 2018-09-12T06:37:08  <luke-jr> (and couldn't be guaranteed by using the same key here either)
109 2018-09-12T06:37:24  <kallewoof> luke-jr: For SignMessage case, yes, but for ProveFunds this becomes a bit of a problem
110 2018-09-12T06:37:44  <luke-jr> kallewoof: does it?
111 2018-09-12T06:37:50  <kallewoof> Unless we all just assume that key_m proves ownership of key_s
112 2018-09-12T06:38:00  <luke-jr> by convention
113 2018-09-12T06:38:20  <kallewoof> Is that sufficient for a proof of funds?
114 2018-09-12T06:38:29  <luke-jr> ProveFunds is confusing anyway; how would a shared wallet with hot/cold separation give fund proofs for all their users?
115 2018-09-12T06:39:01  <luke-jr> I'd guess they'd reuse the same UTXOs, and the convention would say something like "this only proves an amount, not specific UTXOs"
116 2018-09-12T06:39:14  <luke-jr> in which case, the key difference is pretty minor IMO?
117 2018-09-12T06:39:39  <kallewoof> Not sure what you mean by "shared wallet" -- are you talking about an exchange wallet or similar now?
118 2018-09-12T06:39:47  <luke-jr> kallewoof: yes, something like that
119 2018-09-12T06:39:59  <luke-jr> multiple people using the same hot/cold wallet combination
120 2018-09-12T06:40:29  <kallewoof> That is probably tricky. They could still prove solvency, but I don't think the exchange could prove anything to individual users
121 2018-09-12T06:41:09  <luke-jr> well, as long as the convention is to only verify the amount, and the hot wallet has sufficient UTXOs, it could work
122 2018-09-12T06:41:33  <luke-jr> of course, if there's separate spending vs message keys, they could possibly just keep all the message keys hot and avoid the overlaps too
123 2018-09-12T06:41:36  <kallewoof> how do i know the exchange didn't prove my X BTC and your X BTC using the same UTXO's?
124 2018-09-12T06:41:44  <luke-jr> kallewoof: maybe they did. is that a problem?
125 2018-09-12T06:42:12  <kallewoof> I would assume a user wants a proof because they wanna make sure the exchange actually has their coins set aside in some fashion
126 2018-09-12T06:42:22  <luke-jr> even with a single user wallet, perhaps I proved I have funds to buy two houses using the same UTXOs ;)
127 2018-09-12T06:42:40  <kallewoof> Hm, right..
128 2018-09-12T06:42:45  <luke-jr> hmm, I was thinking the user wants to prove to someone else
129 2018-09-12T06:43:02  <luke-jr> proof of solvency might be a specialised case that needs a third type? :/
130 2018-09-12T06:44:15  <luke-jr> I guess the only way to prove funds uniquely, is to escrow them
131 2018-09-12T06:44:20  <kallewoof> I admit I don't know enough about how a proof of solvency would work to comment.
132 2018-09-12T06:44:30  <luke-jr> IIRC petertodd has dabbled in that area
133 2018-09-12T06:44:53  <kallewoof> He has? Didn't know. Will try to find
134 2018-09-12T06:52:08  <kallewoof> luke-jr: To backtrack a bit, you're for using a transaction pair to do the verification thing, right? Is that to allow dusty DSM:s or are there other benefits that I haven't thought/heard of yet? (achow101 noted it would be simpler to do tx based, so that's another one I guess)
135 2018-09-12T06:52:43  <kallewoof> luke-jr: I guess the OP_MESSAGEONLY approach would let you prove without revealing the pubkey which is nice
136 2018-09-12T06:52:50  *** grubles has quit IRC
137 2018-09-12T06:53:41  <kallewoof> luke-jr: Actually, you can still do that even w/o transactions, since the verification call executes the scripts as is. I.e. even w/o transactions, you can do the key_m/_s stuff.
138 2018-09-12T06:55:11  *** grubles has joined #bitcoin-core-dev
139 2018-09-12T06:56:45  <gmaxwell> I don't see _any_ value in message signing that uses special opcodes.
140 2018-09-12T06:57:06  <gmaxwell> There is value in being able to sign with an existing script pubkey, because then you can at least sign with the same criteria used to spend coins.
141 2018-09-12T06:57:21  <gmaxwell> Making something that isn't that is just going down the route of reinventing gpg.
142 2018-09-12T06:57:38  <luke-jr> kallewoof: I don't see any strong reason to care if it's tx pair format or not. But I haven't read the whole thread, so maybe there's a reason for it
143 2018-09-12T06:58:43  <gmaxwell> Tx format is nice, because it allows near perfect reuse of code. Which, assuming the goal is "be able to sign with existant coins" (for example) thats a pretty good match.
144 2018-09-12T06:59:02  *** Guyver2 has joined #bitcoin-core-dev
145 2018-09-12T07:01:15  <luke-jr> gmaxwell: re special opcodes, think of it as pay-to-contract, but with the contract separate and updatable? (and people can always opt not to use the special opcodes if they want to share a key)
146 2018-09-12T07:02:10  <sipa_> what's the point?
147 2018-09-12T07:03:02  *** setpill has joined #bitcoin-core-dev
148 2018-09-12T07:03:24  <luke-jr> the whole purpose of (the current) signed messages is to verify the [future] recipient of a payment agrees to terms before making the payment
149 2018-09-12T07:03:51  <luke-jr> I don't see how using a separate key hurts that at all
150 2018-09-12T07:04:53  *** setpill has quit IRC
151 2018-09-12T07:05:25  <sipa_> i must be missing something, but what is being proven, if it's not the same key?
152 2018-09-12T07:05:48  <luke-jr> that the recipient agrees to some terms
153 2018-09-12T07:06:32  <sipa_> but how do you know it's the recipient?
154 2018-09-12T07:06:39  *** promag has joined #bitcoin-core-dev
155 2018-09-12T07:06:45  <luke-jr> because it's the address you're paying
156 2018-09-12T07:07:08  <sipa_> i'm very confused
157 2018-09-12T07:07:26  <sipa_> i'll read the ML posts later :)
158 2018-09-12T07:07:27  *** setpill has joined #bitcoin-core-dev
159 2018-09-12T07:07:56  <kallewoof> sipa_: No one is responding on the ML unfortunately, but there are comments on the PR
160 2018-09-12T07:08:28  <kallewoof> To be honest, I get more confused as time passes. I didn't realize there were so many different opinions on so many aspects of this.
161 2018-09-12T07:08:53  <luke-jr> :/
162 2018-09-12T07:09:47  <sipa_> kallewoof: yeah, don't bring works in progress to the ML, you'll just get bikeshedding and design by committee :)
163 2018-09-12T07:10:36  <kallewoof> lol
164 2018-09-12T07:11:39  <kallewoof> I think I'll make a section describing how to convert to/from transaction pair format and then let implementers choose whether they go the optional step. That would give them  the ability to pass onto set-in-stone HSM:s.
165 2018-09-12T07:12:58  <sipa_> also don't have optional features that you aren't sure when people would use them :_
166 2018-09-12T07:13:04  <sipa_> they don't know better than you
167 2018-09-12T07:14:28  <kallewoof> Optional features, like the transaction pair conversion? It seems like it could be useful for some people, considering like... 4-5 people have already said they would prefer it to be IN that format.
168 2018-09-12T07:14:51  <kallewoof> (and an equal amount of people have said they prefer it wasn't)
169 2018-09-12T07:15:34  <sipa_> meh
170 2018-09-12T07:15:38  <sipa_> make a choice
171 2018-09-12T07:15:56  <kallewoof> Fair enough.
172 2018-09-12T07:16:27  <sipa_> if you can't write explicit advice "in case A, you should use this, otherwise you should use that", it shouldn't be an optional feature
173 2018-09-12T07:18:13  * sipa_ zZzZ
174 2018-09-12T07:21:24  *** promag has quit IRC
175 2018-09-12T07:28:39  <aj> kallewoof: solvency proofs are "all my debts are in this merkle tree, whose total value is X; here's proof of funds of value Y; Y >= X" possibly with some zkp magic to avoid revealing X or Y. https://crypto.stanford.edu/~dabo/pubs/abstracts/provisions.html
176 2018-09-12T07:29:10  <kallewoof> aj: Nice. Thanks, will read
177 2018-09-12T07:33:49  *** promag has joined #bitcoin-core-dev
178 2018-09-12T07:35:26  *** promag has quit IRC
179 2018-09-12T08:24:02  *** contrapumpkin has joined #bitcoin-core-dev
180 2018-09-12T08:24:33  *** copumpkin has quit IRC
181 2018-09-12T08:24:54  *** miknotauro has joined #bitcoin-core-dev
182 2018-09-12T08:32:51  <wumpus> c++ shouldn't need ? 1 : 0 for booleans, right?
183 2018-09-12T08:34:41  <wumpus> e.g. a bool will always coerce to either 0 or 1
184 2018-09-12T08:36:39  <aj> wumpus: yeah, https://en.cppreference.com/w/cpp/language/implicit_conversion ("Integral promotion" section)
185 2018-09-12T08:37:24  <wumpus> ok there's some discussion about this in #14195 (which solves an actual issue as well, but also adds this confusion)
186 2018-09-12T08:37:26  <gribble> https://github.com/bitcoin/bitcoin/issues/14195 | fix export privkey der always compressed by fingera · Pull Request #14195 · bitcoin/bitcoin · GitHub
187 2018-09-12T08:37:52  <wumpus> but good to hear I didn't make this up :)
188 2018-09-12T08:41:15  <aj> it's a clang readability warning... https://clang.llvm.org/extra/clang-tidy/checks/readability-implicit-bool-conversion.html
189 2018-09-12T08:41:52  <wumpus> I don't think the added compexity really makes it more readable
190 2018-09-12T08:42:12  <wumpus> let's type more to make the compiler happy
191 2018-09-12T08:43:08  <wumpus> aanyhow I'll tell him to squash it and we can merge it, no need to get held up on this, though I do think practicalswift is kind of going too far here in seeding confusion
192 2018-09-12T08:44:42  <aj> seems like ec_privkey_export_der should be accepting a bool rather than an int anyway?
193 2018-09-12T08:45:25  <wumpus> unfortunately secp256k1 lives in 1989, booleans weren't invented back then
194 2018-09-12T08:46:35  <aj> ... it's in src/key.cpp as well as secp256k1/ ?
195 2018-09-12T08:46:42  <aj> i'm confused :(
196 2018-09-12T08:46:59  <wumpus> it's calling a secp256k1 function right? or not?
197 2018-09-12T08:47:17  <wumpus> no, I'm sure I'm confused
198 2018-09-12T08:47:34  <aj> i think it's cut and pasted from secp256k1 into src/key.cpp and marked as static?
199 2018-09-12T08:47:47  <wumpus> AhhhAHHhahHa
200 2018-09-12T08:51:55  <wumpus> you're completely right: there is a ec_privkey_export_der function in secp256k1, but it is not used by us, we have our own version
201 2018-09-12T08:52:25  <wumpus> which could, if we're willing to diverge from upstream take an ActuallyBool
202 2018-09-12T08:54:09  <wumpus> (we have already diverged from upstream in some regards, in 63179d028347bf3e32c7ea61386df4c44307b4a7)
203 2018-09-12T08:54:21  <aj> we've already diverged in a few trivial ways, more so for the _import_der version
204 2018-09-12T08:54:28  <wumpus> yep !
205 2018-09-12T08:58:35  <wumpus> changing the argument to bool is the most sensible solution, suggested it in the PR
206 2018-09-12T09:10:42  *** timothy has joined #bitcoin-core-dev
207 2018-09-12T09:17:09  *** Guyver2 has quit IRC
208 2018-09-12T09:21:03  *** intcat has quit IRC
209 2018-09-12T09:22:33  *** intcat has joined #bitcoin-core-dev
210 2018-09-12T09:51:26  *** Chris_Stewart_5 has joined #bitcoin-core-dev
211 2018-09-12T10:21:35  *** promag has joined #bitcoin-core-dev
212 2018-09-12T10:23:14  *** RubenSomsen has joined #bitcoin-core-dev
213 2018-09-12T10:23:26  *** promag has quit IRC
214 2018-09-12T10:24:24  *** promag has joined #bitcoin-core-dev
215 2018-09-12T10:24:27  *** promag has quit IRC
216 2018-09-12T10:26:39  *** promag has joined #bitcoin-core-dev
217 2018-09-12T10:59:38  *** Chris_Stewart_5 has quit IRC
218 2018-09-12T11:05:48  *** sipa_ has quit IRC
219 2018-09-12T11:06:06  *** sipa has joined #bitcoin-core-dev
220 2018-09-12T11:08:41  *** promag has quit IRC
221 2018-09-12T11:08:44  *** AaronvanW has joined #bitcoin-core-dev
222 2018-09-12T11:17:48  <wumpus> - #12283 `1b06ed1` Fix typos (practicalswift) - #12393 `108af52` Fix a-vs-an typos (practicalswift) - #12543 `480f426` Fix typos (practicalswift) - #12747 `2b1c50b` Fix typos (practicalswift) - #13069 `472fe8a` Fix typos (practicalswift) - #13052 `5713994` Fix relevent typo (practicalswift)
223 2018-09-12T11:17:50  <gribble> https://github.com/bitcoin/bitcoin/issues/12283 | Fix typos by practicalswift · Pull Request #12283 · bitcoin/bitcoin · GitHub
224 2018-09-12T11:17:51  <gribble> https://github.com/bitcoin/bitcoin/issues/12393 | Fix a-vs-an typos by practicalswift · Pull Request #12393 · bitcoin/bitcoin · GitHub
225 2018-09-12T11:17:53  <gribble> https://github.com/bitcoin/bitcoin/issues/12543 | Fix typos by practicalswift · Pull Request #12543 · bitcoin/bitcoin · GitHub
226 2018-09-12T11:17:54  <gribble> https://github.com/bitcoin/bitcoin/issues/13069 | docs: Fix typos by practicalswift · Pull Request #13069 · bitcoin/bitcoin · GitHub
227 2018-09-12T11:17:55  <gribble> https://github.com/bitcoin/bitcoin/issues/12747 | Fix typos by practicalswift · Pull Request #12747 · bitcoin/bitcoin · GitHub
228 2018-09-12T11:17:56  <gribble> https://github.com/bitcoin/bitcoin/issues/13052 | trivial: Fix relevent typo by practicalswift · Pull Request #13052 · bitcoin/bitcoin · GitHub
229 2018-09-12T11:17:57  <wumpus> how many typos fixes do we nee din a release, sigh
230 2018-09-12T11:18:22  <wumpus> whoops didn't mean to trigger the bot
231 2018-09-12T11:36:21  <wumpus> I've added the list of pulls and authors to: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.17.0-Release-notes
232 2018-09-12T11:37:41  *** tryphe_ has joined #bitcoin-core-dev
233 2018-09-12T11:39:27  *** tryphe has quit IRC
234 2018-09-12T11:45:08  *** Fuzzbawls has quit IRC
235 2018-09-12T11:45:53  *** Chris_Stewart_5 has joined #bitcoin-core-dev
236 2018-09-12T12:07:22  *** da2ce7 has quit IRC
237 2018-09-12T12:09:51  *** Jmabsd has joined #bitcoin-core-dev
238 2018-09-12T12:10:49  <Jmabsd> Where in Bitcoin's source code is the TxFee estimation logics for when planning to make a transaction?
239 2018-09-12T12:12:21  <wumpus> src/policy/fees.cpp mainly
240 2018-09-12T12:14:19  <Jmabsd> Thanks!
241 2018-09-12T12:19:04  *** Chris_Stewart_5 has quit IRC
242 2018-09-12T12:19:41  *** Krellan has quit IRC
243 2018-09-12T12:20:23  *** Krellan has joined #bitcoin-core-dev
244 2018-09-12T12:25:16  *** SopaXorzTaker has joined #bitcoin-core-dev
245 2018-09-12T12:26:30  *** molz has quit IRC
246 2018-09-12T12:27:19  *** molz has joined #bitcoin-core-dev
247 2018-09-12T12:43:33  *** wumpus has quit IRC
248 2018-09-12T12:43:56  *** wumpus has joined #bitcoin-core-dev
249 2018-09-12T12:44:07  *** setpill has quit IRC
250 2018-09-12T13:00:21  <echeveria> 
251 2018-09-12T13:00:37  <Jmabsd> wumpus: do you know how the fee estimations are estimated?   the code goes something like ""a 60% threshold required at target / 2, an 85% threshold required at target and a 95% threshold required at 2 * target ... Conservative estimates, however, required the 95% threshold at 2 * target", so, there are three different algorithms running, i don't understand the sense
252 2018-09-12T13:09:22  <wumpus> fee estimation is indeed very complicated
253 2018-09-12T13:09:59  <wumpus> I don't know all the details either
254 2018-09-12T13:18:12  *** Chris_Stewart_5 has joined #bitcoin-core-dev
255 2018-09-12T13:23:51  <wumpus> this is the right place to ask specific questions about the code though, though I'll likely not be able to answer them, someone else might...
256 2018-09-12T13:25:10  <aj> https://bitcointechtalk.com/an-introduction-to-bitcoin-core-fee-estimation-27920880ad0 might be a good place to start
257 2018-09-12T13:50:47  *** elichai2 has joined #bitcoin-core-dev
258 2018-09-12T13:51:03  *** promag has joined #bitcoin-core-dev
259 2018-09-12T14:01:21  *** contrapumpkin has quit IRC
260 2018-09-12T14:02:12  *** SopaXorzTaker has quit IRC
261 2018-09-12T14:02:47  *** copumpkin has joined #bitcoin-core-dev
262 2018-09-12T14:07:04  *** itaseski has joined #bitcoin-core-dev
263 2018-09-12T14:30:12  *** Krellan has quit IRC
264 2018-09-12T14:30:48  *** Krellan has joined #bitcoin-core-dev
265 2018-09-12T14:31:52  *** phwalkr has joined #bitcoin-core-dev
266 2018-09-12T14:44:42  *** michaelsdunn1 has joined #bitcoin-core-dev
267 2018-09-12T15:11:27  *** Victorsueca has quit IRC
268 2018-09-12T15:12:46  *** Victorsueca has joined #bitcoin-core-dev
269 2018-09-12T15:58:15  <wumpus> yes that's a good overview
270 2018-09-12T15:59:27  *** jarthur has joined #bitcoin-core-dev
271 2018-09-12T16:04:15  *** jarthur has quit IRC
272 2018-09-12T16:04:18  *** Jmabsd has quit IRC
273 2018-09-12T16:04:38  *** rex4539 has joined #bitcoin-core-dev
274 2018-09-12T16:15:16  *** promag has quit IRC
275 2018-09-12T16:24:21  *** grubles has quit IRC
276 2018-09-12T16:28:09  *** Zenton has quit IRC
277 2018-09-12T16:28:37  *** Zenton has joined #bitcoin-core-dev
278 2018-09-12T16:34:15  *** escrivner has joined #bitcoin-core-dev
279 2018-09-12T16:35:07  *** escrivner has quit IRC
280 2018-09-12T16:35:31  *** Victorsueca has quit IRC
281 2018-09-12T16:35:45  *** escrivner has joined #bitcoin-core-dev
282 2018-09-12T16:36:46  *** Victorsueca has joined #bitcoin-core-dev
283 2018-09-12T16:36:57  *** escrivner has left #bitcoin-core-dev
284 2018-09-12T16:38:21  *** jarthur has joined #bitcoin-core-dev
285 2018-09-12T16:42:13  *** SopaXorzTaker has joined #bitcoin-core-dev
286 2018-09-12T16:48:10  *** nullptr| has quit IRC
287 2018-09-12T16:49:09  *** nullptr| has joined #bitcoin-core-dev
288 2018-09-12T17:03:34  *** str4d has joined #bitcoin-core-dev
289 2018-09-12T17:03:58  *** grubles has joined #bitcoin-core-dev
290 2018-09-12T17:11:01  *** grubles has quit IRC
291 2018-09-12T17:11:28  *** grubles has joined #bitcoin-core-dev
292 2018-09-12T17:29:24  *** rex4539 has quit IRC
293 2018-09-12T17:30:49  *** drexl has joined #bitcoin-core-dev
294 2018-09-12T17:37:37  *** Tennis has joined #bitcoin-core-dev
295 2018-09-12T17:39:27  *** Tennis has joined #bitcoin-core-dev
296 2018-09-12T17:43:09  *** timothy has quit IRC
297 2018-09-12T18:17:22  *** opdenkamp has joined #bitcoin-core-dev
298 2018-09-12T18:18:45  *** nullptr| has quit IRC
299 2018-09-12T18:23:29  *** nullptr| has joined #bitcoin-core-dev
300 2018-09-12T18:28:57  *** str4d has quit IRC
301 2018-09-12T18:39:58  *** harrigan has joined #bitcoin-core-dev
302 2018-09-12T18:46:02  *** Krellan has quit IRC
303 2018-09-12T18:46:56  *** Krellan has joined #bitcoin-core-dev
304 2018-09-12T18:50:12  *** miknotauro has quit IRC
305 2018-09-12T18:55:33  *** jarthur has quit IRC
306 2018-09-12T19:30:03  *** promag has joined #bitcoin-core-dev
307 2018-09-12T19:38:59  *** Guyver2 has joined #bitcoin-core-dev
308 2018-09-12T19:40:46  *** rex4539 has joined #bitcoin-core-dev
309 2018-09-12T19:52:35  *** SopaXorzTaker has quit IRC
310 2018-09-12T19:55:54  *** RubenSomsen has quit IRC
311 2018-09-12T19:59:03  *** jarthur has joined #bitcoin-core-dev
312 2018-09-12T20:05:44  *** arubi has quit IRC
313 2018-09-12T20:06:24  *** arubi has joined #bitcoin-core-dev
314 2018-09-12T20:20:35  <instagibbs> quick N(ACK)s please: hidden(?) RPC calls exposing compact blocks work flow. We have use in Elements/Liquid for passing blocks around the federation outside of p2p.
315 2018-09-12T20:20:47  <instagibbs> (N)ACKs* :)
316 2018-09-12T20:21:29  <gmaxwell> so you want basically a GETCOMPACTBLOCK and a SUBMITCOMPACTBLOCK?
317 2018-09-12T20:21:36  <instagibbs> ~much yeah
318 2018-09-12T20:21:41  <andytoshi> also a way to get tx indices
319 2018-09-12T20:21:52  <andytoshi> missing tx indices*
320 2018-09-12T20:21:58  <instagibbs> andytoshi, that message already exists
321 2018-09-12T20:22:04  <andytoshi> oh ok ignore me
322 2018-09-12T20:22:40  <instagibbs> and "consume" compact block, which returns the indices, then responding to getblocktxn, yada
323 2018-09-12T20:23:02  <gmaxwell> I don't see any harm in it. I'm not sure if it would have much use, the json serialization/deserialization is going to be slow, perhaps slow enough that this wouldn't be interesting for anyone to build alternative transports.  Might it be more interesting to have a hidden generic RPC that lets you send any P2P message?
324 2018-09-12T20:23:58  <instagibbs> I'll take that as 0+ :P
325 2018-09-12T20:24:09  <gmaxwell> yea, it's a 0+
326 2018-09-12T20:24:22  <andytoshi> hmm actually a hidden generic RPC would be better imho
327 2018-09-12T20:24:42  <instagibbs> andytoshi, seems useful overall, I'd have to think about our application a bit more
328 2018-09-12T20:24:52  <instagibbs> i'll take a swing at it
329 2018-09-12T20:24:57  <gmaxwell> I'm not opposed it it but skeptical that its all that useful for bitcoin in general. I suggested the generic because I could imagine more uses for that. (even if just test shims)
330 2018-09-12T20:25:06  <andytoshi> this isn't the first time i've considered connecting to p2p alongside rpc to get extra stuff
331 2018-09-12T20:25:21  <instagibbs> one * is that we're passing unsigned blocks(kalle's signet may also want something like this)
332 2018-09-12T20:25:30  <instagibbs> which means it'll fail PoW checks
333 2018-09-12T20:25:48  <gmaxwell> Oh I see, you actually want to use compact blocks for pre-pow blocks.
334 2018-09-12T20:25:54  <gmaxwell> BlueMatt: ^ this might be relevant to your interests too.
335 2018-09-12T20:26:14  <gmaxwell> (as matt's mining protocol work also exchanges not-pow-valid-blocks)
336 2018-09-12T20:26:29  <sipa> andytoshi: there may be good reasons to do so; p2p is far more optimized than rpc
337 2018-09-12T20:26:58  <gmaxwell> in general passing through the json is going to hurt performance alone.
338 2018-09-12T20:29:45  <BlueMatt> instagibbs: I dont think the compact block protocol makes sense for low-bandwidth relay outside of p2p
339 2018-09-12T20:30:49  <BlueMatt> oh, wait, scratch that, I was thinking the wrong direction
340 2018-09-12T20:32:31  <BlueMatt> that said, I'm with gmaxwell, I'm skeptical anyone would use it, because its round-trip-required its not really gonna be all that much better for most use-cases
341 2018-09-12T20:33:40  <BlueMatt> eg if you're in a protocol where one side is pushing out to multiple clients it doesnt make any sense, and doesn't make any sense for unidirectional things ala blocksat
342 2018-09-12T20:34:39  <gmaxwell> BlueMatt: well in the one side pushing, much more efficient things are possible but compact blocks already exists and is at least a large constant factor better than sending out the whole block.
343 2018-09-12T20:35:02  <BlueMatt> you misunderstood my point there, by "one side pushing" i meant any unidirectional comms
344 2018-09-12T20:35:23  <BlueMatt> eg blocksat, betterhash effecient block relay, etc
345 2018-09-12T20:35:45  <BlueMatt> or weak block style things
346 2018-09-12T20:37:47  <gmaxwell> yea, okay, sure, but unidirectional is kind of a special case. The betterhash thing could support round trips, no?
347 2018-09-12T20:38:43  <BlueMatt> well round trips means bad performance if you're mega-latency-sensitive
348 2018-09-12T20:39:11  <BlueMatt> so betterhash *could* (with more complication of an already-overcomplicated-protocol imo), but then you'd break anything like running betterhash over quic to get low-latency
349 2018-09-12T20:39:18  <gmaxwell> fair point. Right your current weak block thing still gets guarenteed no RT.
350 2018-09-12T20:39:43  <gmaxwell> BlueMatt: s/latency sensitive/latency sensitive OR on very high latency links/
351 2018-09-12T20:39:51  <BlueMatt> yea
352 2018-09-12T20:40:02  *** Giszmo has joined #bitcoin-core-dev
353 2018-09-12T20:41:29  <jarthur> Would Lightning Network watchtowers have such a use-case?
354 2018-09-12T20:42:27  <gmaxwell> I'm not aware of lightning watchtowers relaying bitcoin blocks.
355 2018-09-12T20:42:38  <BlueMatt> yea, I dont see why that would be needed?
356 2018-09-12T20:42:53  <jarthur> Yea, n/m, my mind is in the pre-conf realm.
357 2018-09-12T20:43:01  <BlueMatt> I'm not aware of any lightning watchtowers.
358 2018-09-12T20:43:36  <BlueMatt> but, yea, instagibbs, I cant say I'm a fan of putting it in the rpc, just seems like vaguely-useless-features that no one will use
359 2018-09-12T20:43:51  <BlueMatt> but otoh I'd doubt its *much* code, so whatever
360 2018-09-12T20:44:01  <gmaxwell> ^ yea my view too.
361 2018-09-12T20:44:15  <BlueMatt> I do plan on putting some able-to-support-compact-encodings-ala-betterhash into core prs soonish, though, cause betterhash needs it
362 2018-09-12T20:44:24  <gmaxwell> alternatively, if there are refactors that would make it easier for you to carry a patch, those would probably be more interesting.
363 2018-09-12T20:44:28  <BlueMatt> but I dont think thats really that related
364 2018-09-12T20:44:54  <instagibbs> alright im -0 it myself, we'll just carry it
365 2018-09-12T20:45:02  <instagibbs> no biggie, thanks for the input
366 2018-09-12T20:45:19  <jarthur> There has been a trend of "personal stratum daemon"s recently, that don't use txindex, might they benefit from such an RPC call?
367 2018-09-12T20:45:55  <gmaxwell> again same question as watchtowers, why would they be relaying blocks to other nodes?
368 2018-09-12T20:50:02  <jarthur> No, but if you took out the stratum daemon, and wanted to just use Core for this purpose, and your light-wallet spoke the language, might there be some benefit from you getting your tx history knowledge in this fashion?
369 2018-09-12T20:50:41  <gmaxwell> No.
370 2018-09-12T20:50:54  <jarthur> I guess making the light wallet speak p2p is just as good?
371 2018-09-12T20:55:33  *** Krellan has quit IRC
372 2018-09-12T20:56:50  *** Krellan has joined #bitcoin-core-dev
373 2018-09-12T20:57:50  <gmaxwell> jarthur: I'm not sure about what parts of the above we read, but we were talking about compact blocks which are _utterly_ useless to litewallets.
374 2018-09-12T20:57:57  <gmaxwell> They're only potentially useful to full nodes.
375 2018-09-12T21:05:14  <jarthur> Cool, sorry, didn't think it through.
376 2018-09-12T21:14:51  <phantomcircuit> i cant decide between setting up Register/Unregister calls for poll/select or replicating the existing logic and setting up the structures every call
377 2018-09-12T21:15:41  <phantomcircuit> the event(ish) based thing is easier to make a mistake with but setting up all the structures is potentially expensive with many peers
378 2018-09-12T21:21:25  <gmaxwell> phantomcircuit: what is easier for people to review and get merged?
379 2018-09-12T21:21:42  <gmaxwell> even if we go with something slower, it can be optimized later.
380 2018-09-12T21:22:03  <gmaxwell> and I doubt anything 'slow' is going to matter with just 125 peers...
381 2018-09-12T21:23:29  <phantomcircuit> rebuilding the structure... maybe?
382 2018-09-12T21:24:07  <phantomcircuit> the logic about whether to set the send/recv flag is surprisingly not trivial so that kind of makes it harder
383 2018-09-12T21:24:19  * phantomcircuit goes off to see
384 2018-09-12T21:29:42  *** Chris_Stewart_5 has quit IRC
385 2018-09-12T21:33:21  *** Guyver2 has quit IRC
386 2018-09-12T21:40:01  *** contrapumpkin has joined #bitcoin-core-dev
387 2018-09-12T21:43:50  *** copumpkin has quit IRC
388 2018-09-12T22:12:07  *** phwalkr has joined #bitcoin-core-dev
389 2018-09-12T22:18:46  *** jhfrontz has joined #bitcoin-core-dev
390 2018-09-12T22:23:03  *** jhfrontz has quit IRC
391 2018-09-12T22:23:15  *** jhfrontz has joined #bitcoin-core-dev
392 2018-09-12T22:24:40  *** michaelsdunn1 has quit IRC
393 2018-09-12T22:28:12  *** Krellan has quit IRC
394 2018-09-12T22:37:42  *** elichai2 has quit IRC
395 2018-09-12T22:44:42  *** Krellan has joined #bitcoin-core-dev
396 2018-09-12T22:46:45  *** grubles has quit IRC
397 2018-09-12T22:46:59  *** grubles has joined #bitcoin-core-dev
398 2018-09-12T22:54:10  *** jhfrontz has quit IRC
399 2018-09-12T22:54:38  *** AaronvanW has quit IRC
400 2018-09-12T22:55:06  *** jhfrontz has joined #bitcoin-core-dev
401 2018-09-12T22:57:59  *** jhfrontz has quit IRC
402 2018-09-12T23:04:00  *** promag has quit IRC
403 2018-09-12T23:17:16  *** Zenton has quit IRC
404 2018-09-12T23:33:38  *** murrayn has quit IRC
405 2018-09-12T23:41:30  *** jarthur has quit IRC
406 2018-09-12T23:42:53  *** murrayn has joined #bitcoin-core-dev
407 2018-09-12T23:43:19  *** Tennis has quit IRC