12018-09-12T00:28:12  *** harrymm has quit IRC
  22018-09-12T00:32:13  *** echonaut has quit IRC
  32018-09-12T00:32:30  *** echonaut has joined #bitcoin-core-dev
  42018-09-12T00:34:34  *** miknotauro has joined #bitcoin-core-dev
  52018-09-12T00:37:42  *** molz has joined #bitcoin-core-dev
  62018-09-12T00:41:19  *** harrymm has joined #bitcoin-core-dev
  72018-09-12T00:46:35  *** molz has quit IRC
  82018-09-12T00:49:52  *** molz has joined #bitcoin-core-dev
  92018-09-12T00:55:49  *** molz has quit IRC
 102018-09-12T01:01:32  *** molz has joined #bitcoin-core-dev
 112018-09-12T01:06:03  *** molz has quit IRC
 122018-09-12T01:07:37  *** Cory has quit IRC
 132018-09-12T01:14:40  *** Cory has joined #bitcoin-core-dev
 142018-09-12T01:19:10  *** Victorsueca has quit IRC
 152018-09-12T01:20:24  *** Victorsueca has joined #bitcoin-core-dev
 162018-09-12T01:22:19  *** sipa_ has joined #bitcoin-core-dev
 172018-09-12T01:25:03  *** sipa has quit IRC
 182018-09-12T01:33:45  *** molz has joined #bitcoin-core-dev
 192018-09-12T01:35:03  *** Chris_Stewart_5 has quit IRC
 202018-09-12T01:57:52  *** unholymachine has quit IRC
 212018-09-12T01:58:17  *** unholymachine has joined #bitcoin-core-dev
 222018-09-12T02:00:30  *** unholymachine has quit IRC
 232018-09-12T03:05:19  *** GoldenBear has quit IRC
 242018-09-12T03:16:59  *** GoldenBear has joined #bitcoin-core-dev
 252018-09-12T03:21:54  *** qrestlove has quit IRC
 262018-09-12T03:26:55  <moneyball> dongcarl your topic mentioned earlier today has been added to the CoreDev list
 272018-09-12T03:27:21  *** qrestlove has joined #bitcoin-core-dev
 282018-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.
 292018-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.
 302018-09-12T03:33:15  *** Krellan has quit IRC
 312018-09-12T04:08:06  *** Victorsueca has quit IRC
 322018-09-12T04:09:20  *** Victorsueca has joined #bitcoin-core-dev
 332018-09-12T04:27:02  *** jarthur has joined #bitcoin-core-dev
 342018-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.
 352018-09-12T04:54:21  <kallewoof> Is he talking about Johnson Lau's OP_MESSAGE comment, maybe..?
 362018-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
 372018-09-12T04:58:46  <kallewoof> luke-jr: Okay...
 382018-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
 392018-09-12T04:59:15  <kallewoof> Unescaped loop injection. What on earth is that anyway?
 402018-09-12T04:59:33  <kallewoof> luke-jr: I don't care about being blocked, tbh. I guess I'll just ask him about it.
 412018-09-12T05:11:47  *** miknotauro has quit IRC
 422018-09-12T05:23:20  *** drexl has quit IRC
 432018-09-12T05:23:51  *** jarthur has quit IRC
 442018-09-12T05:30:48  <gmaxwell> kallewoof: guy appears to just be a drug addict nutcase from prior discussions I saw from him.
 452018-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.
 462018-09-12T05:33:40  <gmaxwell> kallewoof: nor does he.
 472018-09-12T05:34:21  <gmaxwell> If no one does, then he can't be wrong. Checkmate Engineers.
 482018-09-12T05:35:22  <sipa_> kallewoof: the proper response is muting him
 492018-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
 502018-09-12T05:38:00  <gmaxwell> just don't let him keep you going by changing the subject.
 512018-09-12T05:38:14  <sipa_> kallewoof: no, mute him, nos
 522018-09-12T05:38:21  <sipa_> there is nothing useful he says
 532018-09-12T05:38:28  <gmaxwell> lol
 542018-09-12T05:38:33  <sipa_> all his claims are total garbage bullshit
 552018-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.
 562018-09-12T05:39:01  <kallewoof> ahh... okay.
 572018-09-12T05:39:32  <gmaxwell> https://twitter.com/DrRoyMurphy/status/1030266403046260736
 582018-09-12T05:39:44  <gmaxwell> (where pieter made a mistake in talking to him)
 592018-09-12T05:41:44  <kallewoof> Ahh... Yeah looks like he is just a slimy clueless person. How quaint..
 602018-09-12T05:54:19  *** grubles has joined #bitcoin-core-dev
 612018-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
 622018-09-12T05:59:43  <kallewoof> The OP_RETURN thing seems like it could be a bit of a pain to implement for verifiers.
 632018-09-12T06:00:36  <kallewoof> Also still looks like 50/50 'want actual transaction format' vs 'do not want  actual transaction format'.
 642018-09-12T06:03:24  <echeveria> I'm not sure why you'd want that.
 652018-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.
 662018-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.
 672018-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.
 682018-09-12T06:06:10  <echeveria> kallewoof: only uncompressed point keys makes it sort of sucky to use for anything non-joke.
 692018-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
 702018-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."
 712018-09-12T06:08:16  <echeveria> that sounds like it's attracting foot gunning, honestly.
 722018-09-12T06:08:31  <kallewoof> Sounds a bit dangerous, yeah.
 732018-09-12T06:11:44  *** Krellan has joined #bitcoin-core-dev
 742018-09-12T06:12:45  *** Krellan has joined #bitcoin-core-dev
 752018-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.
 762018-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"
 772018-09-12T06:19:16  <echeveria> aj: agreed entirely.
 782018-09-12T06:22:47  <kallewoof> aj: That's a good way of putting it
 792018-09-12T06:23:05  <aj> kallewoof: i wonder if adding an input txid=00..00,n=0,value=21e14 would be an interesting invalidator?
 802018-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.
 812018-09-12T06:26:05  <aj> kallewoof: i'm still trying to form an opinion :)
 822018-09-12T06:26:20  <kallewoof> Ahh, okay
 832018-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
 842018-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
 852018-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?
 862018-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?
 872018-09-12T06:29:20  <echeveria> if it's a dumb interface that signs anything hat comes to it, sounds like a shitty HSM.
 882018-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
 892018-09-12T06:30:03  <echeveria> for the former, I'm not sure this hack would work a lot of the time anyway.
 902018-09-12T06:31:06  <luke-jr> it would be nice if it was such that scripts could have a different execution path for messages
 912018-09-12T06:31:18  <aj> luke-jr: why??
 922018-09-12T06:31:38  <echeveria> ?
 932018-09-12T06:32:00  <kallewoof> I think that's what Johnson Lau wants with the OP_MESSAGEONLY opcode?
 942018-09-12T06:32:09  <aj> luke-jr: jl2012's OP_MESSAGEONLY or OP_RETURN special handlying does that, but i don't get why
 952018-09-12T06:32:25  *** Victorsueca has quit IRC
 962018-09-12T06:32:29  <kallewoof> "OP_IF OP_MESSAGEONLY <key_m> OP_ELSE <key_s> OP_ENDIF OP_CHECKSIG"
 972018-09-12T06:32:39  <kallewoof> (https://github.com/bitcoin/bips/pull/725#issuecomment-420421058)
 982018-09-12T06:32:40  <luke-jr> aj: so you can sign with a key that can't spend
 992018-09-12T06:32:55  <echeveria> lol no
1002018-09-12T06:33:21  <luke-jr> aj: and thereby avoid multiple signatures with the same key
1012018-09-12T06:33:42  *** Victorsueca has joined #bitcoin-core-dev
1022018-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
1032018-09-12T06:34:33  <kallewoof> key_m would be signing that you know key_s, though
1042018-09-12T06:34:44  <aj> kallewoof: claiming, but not proving
1052018-09-12T06:34:48  <luke-jr> aj: you might not want to disclose the spending pubkey
1062018-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
1072018-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
1082018-09-12T06:37:08  <luke-jr> (and couldn't be guaranteed by using the same key here either)
1092018-09-12T06:37:24  <kallewoof> luke-jr: For SignMessage case, yes, but for ProveFunds this becomes a bit of a problem
1102018-09-12T06:37:44  <luke-jr> kallewoof: does it?
1112018-09-12T06:37:50  <kallewoof> Unless we all just assume that key_m proves ownership of key_s
1122018-09-12T06:38:00  <luke-jr> by convention
1132018-09-12T06:38:20  <kallewoof> Is that sufficient for a proof of funds?
1142018-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?
1152018-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"
1162018-09-12T06:39:14  <luke-jr> in which case, the key difference is pretty minor IMO?
1172018-09-12T06:39:39  <kallewoof> Not sure what you mean by "shared wallet" -- are you talking about an exchange wallet or similar now?
1182018-09-12T06:39:47  <luke-jr> kallewoof: yes, something like that
1192018-09-12T06:39:59  <luke-jr> multiple people using the same hot/cold wallet combination
1202018-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
1212018-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
1222018-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
1232018-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?
1242018-09-12T06:41:44  <luke-jr> kallewoof: maybe they did. is that a problem?
1252018-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
1262018-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 ;)
1272018-09-12T06:42:40  <kallewoof> Hm, right..
1282018-09-12T06:42:45  <luke-jr> hmm, I was thinking the user wants to prove to someone else
1292018-09-12T06:43:02  <luke-jr> proof of solvency might be a specialised case that needs a third type? :/
1302018-09-12T06:44:15  <luke-jr> I guess the only way to prove funds uniquely, is to escrow them
1312018-09-12T06:44:20  <kallewoof> I admit I don't know enough about how a proof of solvency would work to comment.
1322018-09-12T06:44:30  <luke-jr> IIRC petertodd has dabbled in that area
1332018-09-12T06:44:53  <kallewoof> He has? Didn't know. Will try to find
1342018-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)
1352018-09-12T06:52:43  <kallewoof> luke-jr: I guess the OP_MESSAGEONLY approach would let you prove without revealing the pubkey which is nice
1362018-09-12T06:52:50  *** grubles has quit IRC
1372018-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.
1382018-09-12T06:55:11  *** grubles has joined #bitcoin-core-dev
1392018-09-12T06:56:45  <gmaxwell> I don't see _any_ value in message signing that uses special opcodes.
1402018-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.
1412018-09-12T06:57:21  <gmaxwell> Making something that isn't that is just going down the route of reinventing gpg.
1422018-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
1432018-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.
1442018-09-12T06:59:02  *** Guyver2 has joined #bitcoin-core-dev
1452018-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)
1462018-09-12T07:02:10  <sipa_> what's the point?
1472018-09-12T07:03:02  *** setpill has joined #bitcoin-core-dev
1482018-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
1492018-09-12T07:03:51  <luke-jr> I don't see how using a separate key hurts that at all
1502018-09-12T07:04:53  *** setpill has quit IRC
1512018-09-12T07:05:25  <sipa_> i must be missing something, but what is being proven, if it's not the same key?
1522018-09-12T07:05:48  <luke-jr> that the recipient agrees to some terms
1532018-09-12T07:06:32  <sipa_> but how do you know it's the recipient?
1542018-09-12T07:06:39  *** promag has joined #bitcoin-core-dev
1552018-09-12T07:06:45  <luke-jr> because it's the address you're paying
1562018-09-12T07:07:08  <sipa_> i'm very confused
1572018-09-12T07:07:26  <sipa_> i'll read the ML posts later :)
1582018-09-12T07:07:27  *** setpill has joined #bitcoin-core-dev
1592018-09-12T07:07:56  <kallewoof> sipa_: No one is responding on the ML unfortunately, but there are comments on the PR
1602018-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.
1612018-09-12T07:08:53  <luke-jr> :/
1622018-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 :)
1632018-09-12T07:10:36  <kallewoof> lol
1642018-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.
1652018-09-12T07:12:58  <sipa_> also don't have optional features that you aren't sure when people would use them :_
1662018-09-12T07:13:04  <sipa_> they don't know better than you
1672018-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.
1682018-09-12T07:14:51  <kallewoof> (and an equal amount of people have said they prefer it wasn't)
1692018-09-12T07:15:34  <sipa_> meh
1702018-09-12T07:15:38  <sipa_> make a choice
1712018-09-12T07:15:56  <kallewoof> Fair enough.
1722018-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
1732018-09-12T07:18:13  * sipa_ zZzZ
1742018-09-12T07:21:24  *** promag has quit IRC
1752018-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
1762018-09-12T07:29:10  <kallewoof> aj: Nice. Thanks, will read
1772018-09-12T07:33:49  *** promag has joined #bitcoin-core-dev
1782018-09-12T07:35:26  *** promag has quit IRC
1792018-09-12T08:24:02  *** contrapumpkin has joined #bitcoin-core-dev
1802018-09-12T08:24:33  *** copumpkin has quit IRC
1812018-09-12T08:24:54  *** miknotauro has joined #bitcoin-core-dev
1822018-09-12T08:32:51  <wumpus> c++ shouldn't need ? 1 : 0 for booleans, right?
1832018-09-12T08:34:41  <wumpus> e.g. a bool will always coerce to either 0 or 1
1842018-09-12T08:36:39  <aj> wumpus: yeah, https://en.cppreference.com/w/cpp/language/implicit_conversion ("Integral promotion" section)
1852018-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)
1862018-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
1872018-09-12T08:37:52  <wumpus> but good to hear I didn't make this up :)
1882018-09-12T08:41:15  <aj> it's a clang readability warning... https://clang.llvm.org/extra/clang-tidy/checks/readability-implicit-bool-conversion.html
1892018-09-12T08:41:52  <wumpus> I don't think the added compexity really makes it more readable
1902018-09-12T08:42:12  <wumpus> let's type more to make the compiler happy
1912018-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
1922018-09-12T08:44:42  <aj> seems like ec_privkey_export_der should be accepting a bool rather than an int anyway?
1932018-09-12T08:45:25  <wumpus> unfortunately secp256k1 lives in 1989, booleans weren't invented back then
1942018-09-12T08:46:35  <aj> ... it's in src/key.cpp as well as secp256k1/ ?
1952018-09-12T08:46:42  <aj> i'm confused :(
1962018-09-12T08:46:59  <wumpus> it's calling a secp256k1 function right? or not?
1972018-09-12T08:47:17  <wumpus> no, I'm sure I'm confused
1982018-09-12T08:47:34  <aj> i think it's cut and pasted from secp256k1 into src/key.cpp and marked as static?
1992018-09-12T08:47:47  <wumpus> AhhhAHHhahHa
2002018-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
2012018-09-12T08:52:25  <wumpus> which could, if we're willing to diverge from upstream take an ActuallyBool
2022018-09-12T08:54:09  <wumpus> (we have already diverged from upstream in some regards, in 63179d028347bf3e32c7ea61386df4c44307b4a7)
2032018-09-12T08:54:21  <aj> we've already diverged in a few trivial ways, more so for the _import_der version
2042018-09-12T08:54:28  <wumpus> yep !
2052018-09-12T08:58:35  <wumpus> changing the argument to bool is the most sensible solution, suggested it in the PR
2062018-09-12T09:10:42  *** timothy has joined #bitcoin-core-dev
2072018-09-12T09:17:09  *** Guyver2 has quit IRC
2082018-09-12T09:21:03  *** intcat has quit IRC
2092018-09-12T09:22:33  *** intcat has joined #bitcoin-core-dev
2102018-09-12T09:51:26  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2112018-09-12T10:21:35  *** promag has joined #bitcoin-core-dev
2122018-09-12T10:23:14  *** RubenSomsen has joined #bitcoin-core-dev
2132018-09-12T10:23:26  *** promag has quit IRC
2142018-09-12T10:24:24  *** promag has joined #bitcoin-core-dev
2152018-09-12T10:24:27  *** promag has quit IRC
2162018-09-12T10:26:39  *** promag has joined #bitcoin-core-dev
2172018-09-12T10:59:38  *** Chris_Stewart_5 has quit IRC
2182018-09-12T11:05:48  *** sipa_ has quit IRC
2192018-09-12T11:06:06  *** sipa has joined #bitcoin-core-dev
2202018-09-12T11:08:41  *** promag has quit IRC
2212018-09-12T11:08:44  *** AaronvanW has joined #bitcoin-core-dev
2222018-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)
2232018-09-12T11:17:50  <gribble> https://github.com/bitcoin/bitcoin/issues/12283 | Fix typos by practicalswift · Pull Request #12283 · bitcoin/bitcoin · GitHub
2242018-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
2252018-09-12T11:17:53  <gribble> https://github.com/bitcoin/bitcoin/issues/12543 | Fix typos by practicalswift · Pull Request #12543 · bitcoin/bitcoin · GitHub
2262018-09-12T11:17:54  <gribble> https://github.com/bitcoin/bitcoin/issues/13069 | docs: Fix typos by practicalswift · Pull Request #13069 · bitcoin/bitcoin · GitHub
2272018-09-12T11:17:55  <gribble> https://github.com/bitcoin/bitcoin/issues/12747 | Fix typos by practicalswift · Pull Request #12747 · bitcoin/bitcoin · GitHub
2282018-09-12T11:17:56  <gribble> https://github.com/bitcoin/bitcoin/issues/13052 | trivial: Fix relevent typo by practicalswift · Pull Request #13052 · bitcoin/bitcoin · GitHub
2292018-09-12T11:17:57  <wumpus> how many typos fixes do we nee din a release, sigh
2302018-09-12T11:18:22  <wumpus> whoops didn't mean to trigger the bot
2312018-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
2322018-09-12T11:37:41  *** tryphe_ has joined #bitcoin-core-dev
2332018-09-12T11:39:27  *** tryphe has quit IRC
2342018-09-12T11:45:08  *** Fuzzbawls has quit IRC
2352018-09-12T11:45:53  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2362018-09-12T12:07:22  *** da2ce7 has quit IRC
2372018-09-12T12:09:51  *** Jmabsd has joined #bitcoin-core-dev
2382018-09-12T12:10:49  <Jmabsd> Where in Bitcoin's source code is the TxFee estimation logics for when planning to make a transaction?
2392018-09-12T12:12:21  <wumpus> src/policy/fees.cpp mainly
2402018-09-12T12:14:19  <Jmabsd> Thanks!
2412018-09-12T12:19:04  *** Chris_Stewart_5 has quit IRC
2422018-09-12T12:19:41  *** Krellan has quit IRC
2432018-09-12T12:20:23  *** Krellan has joined #bitcoin-core-dev
2442018-09-12T12:25:16  *** SopaXorzTaker has joined #bitcoin-core-dev
2452018-09-12T12:26:30  *** molz has quit IRC
2462018-09-12T12:27:19  *** molz has joined #bitcoin-core-dev
2472018-09-12T12:43:33  *** wumpus has quit IRC
2482018-09-12T12:43:56  *** wumpus has joined #bitcoin-core-dev
2492018-09-12T12:44:07  *** setpill has quit IRC
2502018-09-12T13:00:21  <echeveria> 
2512018-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
2522018-09-12T13:09:22  <wumpus> fee estimation is indeed very complicated
2532018-09-12T13:09:59  <wumpus> I don't know all the details either
2542018-09-12T13:18:12  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2552018-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...
2562018-09-12T13:25:10  <aj> https://bitcointechtalk.com/an-introduction-to-bitcoin-core-fee-estimation-27920880ad0 might be a good place to start
2572018-09-12T13:50:47  *** elichai2 has joined #bitcoin-core-dev
2582018-09-12T13:51:03  *** promag has joined #bitcoin-core-dev
2592018-09-12T14:01:21  *** contrapumpkin has quit IRC
2602018-09-12T14:02:12  *** SopaXorzTaker has quit IRC
2612018-09-12T14:02:47  *** copumpkin has joined #bitcoin-core-dev
2622018-09-12T14:07:04  *** itaseski has joined #bitcoin-core-dev
2632018-09-12T14:30:12  *** Krellan has quit IRC
2642018-09-12T14:30:48  *** Krellan has joined #bitcoin-core-dev
2652018-09-12T14:31:52  *** phwalkr has joined #bitcoin-core-dev
2662018-09-12T14:44:42  *** michaelsdunn1 has joined #bitcoin-core-dev
2672018-09-12T15:11:27  *** Victorsueca has quit IRC
2682018-09-12T15:12:46  *** Victorsueca has joined #bitcoin-core-dev
2692018-09-12T15:58:15  <wumpus> yes that's a good overview
2702018-09-12T15:59:27  *** jarthur has joined #bitcoin-core-dev
2712018-09-12T16:04:15  *** jarthur has quit IRC
2722018-09-12T16:04:18  *** Jmabsd has quit IRC
2732018-09-12T16:04:38  *** rex4539 has joined #bitcoin-core-dev
2742018-09-12T16:15:16  *** promag has quit IRC
2752018-09-12T16:24:21  *** grubles has quit IRC
2762018-09-12T16:28:09  *** Zenton has quit IRC
2772018-09-12T16:28:37  *** Zenton has joined #bitcoin-core-dev
2782018-09-12T16:34:15  *** escrivner has joined #bitcoin-core-dev
2792018-09-12T16:35:07  *** escrivner has quit IRC
2802018-09-12T16:35:31  *** Victorsueca has quit IRC
2812018-09-12T16:35:45  *** escrivner has joined #bitcoin-core-dev
2822018-09-12T16:36:46  *** Victorsueca has joined #bitcoin-core-dev
2832018-09-12T16:36:57  *** escrivner has left #bitcoin-core-dev
2842018-09-12T16:38:21  *** jarthur has joined #bitcoin-core-dev
2852018-09-12T16:42:13  *** SopaXorzTaker has joined #bitcoin-core-dev
2862018-09-12T16:48:10  *** nullptr| has quit IRC
2872018-09-12T16:49:09  *** nullptr| has joined #bitcoin-core-dev
2882018-09-12T17:03:34  *** str4d has joined #bitcoin-core-dev
2892018-09-12T17:03:58  *** grubles has joined #bitcoin-core-dev
2902018-09-12T17:11:01  *** grubles has quit IRC
2912018-09-12T17:11:28  *** grubles has joined #bitcoin-core-dev
2922018-09-12T17:29:24  *** rex4539 has quit IRC
2932018-09-12T17:30:49  *** drexl has joined #bitcoin-core-dev
2942018-09-12T17:37:37  *** Tennis has joined #bitcoin-core-dev
2952018-09-12T17:39:27  *** Tennis has joined #bitcoin-core-dev
2962018-09-12T17:43:09  *** timothy has quit IRC
2972018-09-12T18:17:22  *** opdenkamp has joined #bitcoin-core-dev
2982018-09-12T18:18:45  *** nullptr| has quit IRC
2992018-09-12T18:23:29  *** nullptr| has joined #bitcoin-core-dev
3002018-09-12T18:28:57  *** str4d has quit IRC
3012018-09-12T18:39:58  *** harrigan has joined #bitcoin-core-dev
3022018-09-12T18:46:02  *** Krellan has quit IRC
3032018-09-12T18:46:56  *** Krellan has joined #bitcoin-core-dev
3042018-09-12T18:50:12  *** miknotauro has quit IRC
3052018-09-12T18:55:33  *** jarthur has quit IRC
3062018-09-12T19:30:03  *** promag has joined #bitcoin-core-dev
3072018-09-12T19:38:59  *** Guyver2 has joined #bitcoin-core-dev
3082018-09-12T19:40:46  *** rex4539 has joined #bitcoin-core-dev
3092018-09-12T19:52:35  *** SopaXorzTaker has quit IRC
3102018-09-12T19:55:54  *** RubenSomsen has quit IRC
3112018-09-12T19:59:03  *** jarthur has joined #bitcoin-core-dev
3122018-09-12T20:05:44  *** arubi has quit IRC
3132018-09-12T20:06:24  *** arubi has joined #bitcoin-core-dev
3142018-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.
3152018-09-12T20:20:47  <instagibbs> (N)ACKs* :)
3162018-09-12T20:21:29  <gmaxwell> so you want basically a GETCOMPACTBLOCK and a SUBMITCOMPACTBLOCK?
3172018-09-12T20:21:36  <instagibbs> ~much yeah
3182018-09-12T20:21:41  <andytoshi> also a way to get tx indices
3192018-09-12T20:21:52  <andytoshi> missing tx indices*
3202018-09-12T20:21:58  <instagibbs> andytoshi, that message already exists
3212018-09-12T20:22:04  <andytoshi> oh ok ignore me
3222018-09-12T20:22:40  <instagibbs> and "consume" compact block, which returns the indices, then responding to getblocktxn, yada
3232018-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?
3242018-09-12T20:23:58  <instagibbs> I'll take that as 0+ :P
3252018-09-12T20:24:09  <gmaxwell> yea, it's a 0+
3262018-09-12T20:24:22  <andytoshi> hmm actually a hidden generic RPC would be better imho
3272018-09-12T20:24:42  <instagibbs> andytoshi, seems useful overall, I'd have to think about our application a bit more
3282018-09-12T20:24:52  <instagibbs> i'll take a swing at it
3292018-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)
3302018-09-12T20:25:06  <andytoshi> this isn't the first time i've considered connecting to p2p alongside rpc to get extra stuff
3312018-09-12T20:25:21  <instagibbs> one * is that we're passing unsigned blocks(kalle's signet may also want something like this)
3322018-09-12T20:25:30  <instagibbs> which means it'll fail PoW checks
3332018-09-12T20:25:48  <gmaxwell> Oh I see, you actually want to use compact blocks for pre-pow blocks.
3342018-09-12T20:25:54  <gmaxwell> BlueMatt: ^ this might be relevant to your interests too.
3352018-09-12T20:26:14  <gmaxwell> (as matt's mining protocol work also exchanges not-pow-valid-blocks)
3362018-09-12T20:26:29  <sipa> andytoshi: there may be good reasons to do so; p2p is far more optimized than rpc
3372018-09-12T20:26:58  <gmaxwell> in general passing through the json is going to hurt performance alone.
3382018-09-12T20:29:45  <BlueMatt> instagibbs: I dont think the compact block protocol makes sense for low-bandwidth relay outside of p2p
3392018-09-12T20:30:49  <BlueMatt> oh, wait, scratch that, I was thinking the wrong direction
3402018-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
3412018-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
3422018-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.
3432018-09-12T20:35:02  <BlueMatt> you misunderstood my point there, by "one side pushing" i meant any unidirectional comms
3442018-09-12T20:35:23  <BlueMatt> eg blocksat, betterhash effecient block relay, etc
3452018-09-12T20:35:45  <BlueMatt> or weak block style things
3462018-09-12T20:37:47  <gmaxwell> yea, okay, sure, but unidirectional is kind of a special case. The betterhash thing could support round trips, no?
3472018-09-12T20:38:43  <BlueMatt> well round trips means bad performance if you're mega-latency-sensitive
3482018-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
3492018-09-12T20:39:18  <gmaxwell> fair point. Right your current weak block thing still gets guarenteed no RT.
3502018-09-12T20:39:43  <gmaxwell> BlueMatt: s/latency sensitive/latency sensitive OR on very high latency links/
3512018-09-12T20:39:51  <BlueMatt> yea
3522018-09-12T20:40:02  *** Giszmo has joined #bitcoin-core-dev
3532018-09-12T20:41:29  <jarthur> Would Lightning Network watchtowers have such a use-case?
3542018-09-12T20:42:27  <gmaxwell> I'm not aware of lightning watchtowers relaying bitcoin blocks.
3552018-09-12T20:42:38  <BlueMatt> yea, I dont see why that would be needed?
3562018-09-12T20:42:53  <jarthur> Yea, n/m, my mind is in the pre-conf realm.
3572018-09-12T20:43:01  <BlueMatt> I'm not aware of any lightning watchtowers.
3582018-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
3592018-09-12T20:43:51  <BlueMatt> but otoh I'd doubt its *much* code, so whatever
3602018-09-12T20:44:01  <gmaxwell> ^ yea my view too.
3612018-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
3622018-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.
3632018-09-12T20:44:28  <BlueMatt> but I dont think thats really that related
3642018-09-12T20:44:54  <instagibbs> alright im -0 it myself, we'll just carry it
3652018-09-12T20:45:02  <instagibbs> no biggie, thanks for the input
3662018-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?
3672018-09-12T20:45:55  <gmaxwell> again same question as watchtowers, why would they be relaying blocks to other nodes?
3682018-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?
3692018-09-12T20:50:41  <gmaxwell> No.
3702018-09-12T20:50:54  <jarthur> I guess making the light wallet speak p2p is just as good?
3712018-09-12T20:55:33  *** Krellan has quit IRC
3722018-09-12T20:56:50  *** Krellan has joined #bitcoin-core-dev
3732018-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.
3742018-09-12T20:57:57  <gmaxwell> They're only potentially useful to full nodes.
3752018-09-12T21:05:14  <jarthur> Cool, sorry, didn't think it through.
3762018-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
3772018-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
3782018-09-12T21:21:25  <gmaxwell> phantomcircuit: what is easier for people to review and get merged?
3792018-09-12T21:21:42  <gmaxwell> even if we go with something slower, it can be optimized later.
3802018-09-12T21:22:03  <gmaxwell> and I doubt anything 'slow' is going to matter with just 125 peers...
3812018-09-12T21:23:29  <phantomcircuit> rebuilding the structure... maybe?
3822018-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
3832018-09-12T21:24:19  * phantomcircuit goes off to see
3842018-09-12T21:29:42  *** Chris_Stewart_5 has quit IRC
3852018-09-12T21:33:21  *** Guyver2 has quit IRC
3862018-09-12T21:40:01  *** contrapumpkin has joined #bitcoin-core-dev
3872018-09-12T21:43:50  *** copumpkin has quit IRC
3882018-09-12T22:12:07  *** phwalkr has joined #bitcoin-core-dev
3892018-09-12T22:18:46  *** jhfrontz has joined #bitcoin-core-dev
3902018-09-12T22:23:03  *** jhfrontz has quit IRC
3912018-09-12T22:23:15  *** jhfrontz has joined #bitcoin-core-dev
3922018-09-12T22:24:40  *** michaelsdunn1 has quit IRC
3932018-09-12T22:28:12  *** Krellan has quit IRC
3942018-09-12T22:37:42  *** elichai2 has quit IRC
3952018-09-12T22:44:42  *** Krellan has joined #bitcoin-core-dev
3962018-09-12T22:46:45  *** grubles has quit IRC
3972018-09-12T22:46:59  *** grubles has joined #bitcoin-core-dev
3982018-09-12T22:54:10  *** jhfrontz has quit IRC
3992018-09-12T22:54:38  *** AaronvanW has quit IRC
4002018-09-12T22:55:06  *** jhfrontz has joined #bitcoin-core-dev
4012018-09-12T22:57:59  *** jhfrontz has quit IRC
4022018-09-12T23:04:00  *** promag has quit IRC
4032018-09-12T23:17:16  *** Zenton has quit IRC
4042018-09-12T23:33:38  *** murrayn has quit IRC
4052018-09-12T23:41:30  *** jarthur has quit IRC
4062018-09-12T23:42:53  *** murrayn has joined #bitcoin-core-dev
4072018-09-12T23:43:19  *** Tennis has quit IRC