12018-08-09T00:05:35 *** rls has quit IRC
22018-08-09T00:10:57 *** justanotherus3r has quit IRC
32018-08-09T00:12:24 *** masonicboom has joined #bitcoin-core-dev
42018-08-09T00:16:51 *** masonicboom has quit IRC
52018-08-09T00:19:20 *** ju5tanotheruser has joined #bitcoin-core-dev
62018-08-09T00:46:12 *** promag has quit IRC
72018-08-09T01:21:33 *** ken2812221 has quit IRC
82018-08-09T01:22:57 *** ken2812221 has joined #bitcoin-core-dev
92018-08-09T01:34:03 *** Chris_Stewart_5 has joined #bitcoin-core-dev
102018-08-09T01:39:22 *** Chris_Stewart_5 has quit IRC
112018-08-09T01:43:54 *** Emcy_ has quit IRC
122018-08-09T02:11:06 *** Krellan has quit IRC
132018-08-09T02:11:41 *** Jmabsd has joined #bitcoin-core-dev
142018-08-09T02:12:12 *** Krellan has joined #bitcoin-core-dev
152018-08-09T02:12:17 *** phwalkr has joined #bitcoin-core-dev
162018-08-09T02:14:45 <Jmabsd> code question, https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1162 - when generating the sign text for OP_CHECKSIG, the code to produce the signtext with respect to one transaction output, is just " ::Serialize(s, txTo.vout[nOutput]);".
172018-08-09T02:15:01 <Jmabsd> Where is the "Serialize" logics for the transaction output (CTxOut)?
182018-08-09T02:59:16 *** ju5tanotheruser has quit IRC
192018-08-09T03:01:09 *** hirish has quit IRC
202018-08-09T03:11:45 *** justanotheruser has joined #bitcoin-core-dev
212018-08-09T03:22:25 <Jmabsd> Where in Bitcoin Core's code are the constraints on what scripts are allowed, implemented? E.g., gossiped transaction's lock scripts must be either of P2PK, P2PKH, multisig, nulldata or P2SH in order to be considered valid and be gossiped?
222018-08-09T03:29:43 *** rls has joined #bitcoin-core-dev
232018-08-09T03:42:36 *** Victorsueca has quit IRC
242018-08-09T03:43:44 *** Victorsueca has joined #bitcoin-core-dev
252018-08-09T03:45:49 *** jhfrontz has quit IRC
262018-08-09T03:47:01 *** d9b4bef9 has quit IRC
272018-08-09T03:48:07 *** d9b4bef9 has joined #bitcoin-core-dev
282018-08-09T03:48:21 *** justanotheruser has quit IRC
292018-08-09T03:49:21 *** justan0theruser has joined #bitcoin-core-dev
302018-08-09T03:54:20 *** justan0theruser is now known as justanotheruser
312018-08-09T03:54:23 <aj> Jmabsd: src/policy/policy.cpp IsStandardTx might be what you want
322018-08-09T03:55:29 <Jmabsd> aj: ah, so Bitcoin Core nodes will accept a nonstandard tx when it's in a block, but it will not accept them in gossiping, right?
332018-08-09T03:57:30 <Jmabsd> aj: do you have any idea where Serialize for CTxOut is?
342018-08-09T04:08:03 *** Jmabsd has quit IRC
352018-08-09T04:09:51 *** phwalkr has quit IRC
362018-08-09T04:24:40 *** andreip_ has joined #bitcoin-core-dev
372018-08-09T04:30:32 *** ken2812221 has quit IRC
382018-08-09T04:45:55 *** G0tCrypt0C01ns has joined #bitcoin-core-dev
392018-08-09T05:01:09 *** G0tCrypt0C01ns has quit IRC
402018-08-09T05:03:29 *** arubi has quit IRC
412018-08-09T05:03:53 *** arubi has joined #bitcoin-core-dev
422018-08-09T05:04:18 *** Jmabsd has joined #bitcoin-core-dev
432018-08-09T05:12:46 <wumpus> Jmabsd: that's the definition of "non-standard", it is relay/mining policy not consensus policy
442018-08-09T05:16:52 <Jmabsd> wumpus: a miner is free to receive nonstandard transactions, right?
452018-08-09T05:17:03 <Jmabsd> and include in blocks, and all nodes will accept those blocks.
462018-08-09T05:17:36 <Jmabsd> Where is the "Serialize" logics for the transaction output (CTxOut)?
472018-08-09T05:19:45 *** andreip_ has quit IRC
482018-08-09T05:19:54 <aj> Jmabsd: see primitives/transaction.h and serialize.h
492018-08-09T05:22:13 <wumpus> a miner is free to do everything accepted by consensus
502018-08-09T05:23:16 <wumpus> so yes, they can include non-standard transactions as long as they're valid in blocks
512018-08-09T05:24:43 <Jmabsd> wumpus: interesting. cool.
522018-08-09T05:24:50 *** jeffrufino has joined #bitcoin-core-dev
532018-08-09T05:26:49 <Jmabsd> aj: ahh, CTxOut has a ADD_SERIALIZE_METHODS. got it.
542018-08-09T05:31:23 <wumpus> indeed--classes implement their own serialization/deserialization
552018-08-09T05:59:44 <aj> wumpus: in case i'm not awake for the meeting, topic suggestion: lower tx fees, pr #13922 :)
562018-08-09T05:59:45 <gribble> https://github.com/bitcoin/bitcoin/issues/13922 | Lower default relay fees by ajtowns · Pull Request #13922 · bitcoin/bitcoin · GitHub
572018-08-09T06:29:21 *** Krellan has quit IRC
582018-08-09T06:29:49 *** Krellan has joined #bitcoin-core-dev
592018-08-09T06:30:17 *** masonicboom has joined #bitcoin-core-dev
602018-08-09T06:35:50 <Jmabsd> wumpus: are only *output scripts* having the standard/nonstandard classification, or also *input scripts* and *P2SH redeem scripts* need to fit a particular template?
612018-08-09T07:01:41 <sipa> Jmabsd: there are various standardness rules
622018-08-09T07:02:06 <sipa> certain scriot opcodes are nonstandard when executed in a spend
632018-08-09T07:02:21 <sipa> there are resource limits like sizes and signature check limits
642018-08-09T07:02:57 <sipa> Jmabsd: https://bitcoin.stackexchange.com may be a better place to ask these things
652018-08-09T07:03:50 <Jmabsd> sipa: hm
662018-08-09T07:15:13 *** AaronvanW has joined #bitcoin-core-dev
672018-08-09T07:25:35 *** SopaXorzTaker has joined #bitcoin-core-dev
682018-08-09T07:43:47 *** ken2812221 has joined #bitcoin-core-dev
692018-08-09T07:49:01 *** d9b4bef9 has quit IRC
702018-08-09T07:50:15 *** d9b4bef9 has joined #bitcoin-core-dev
712018-08-09T08:01:57 *** ken2812221 has quit IRC
722018-08-09T08:03:08 *** ken2812221 has joined #bitcoin-core-dev
732018-08-09T08:38:20 *** timothy has joined #bitcoin-core-dev
742018-08-09T08:46:04 *** masonicboom has quit IRC
752018-08-09T08:46:11 *** AaronvanW has quit IRC
762018-08-09T09:10:31 *** Guyver2 has joined #bitcoin-core-dev
772018-08-09T09:11:10 *** fanquake has joined #bitcoin-core-dev
782018-08-09T09:17:17 *** vicenteH has joined #bitcoin-core-dev
792018-08-09T09:29:54 *** Jmabsd has quit IRC
802018-08-09T09:46:24 *** csknk has joined #bitcoin-core-dev
812018-08-09T09:56:25 *** Emcy_ has joined #bitcoin-core-dev
822018-08-09T10:32:00 *** Chris_Stewart_5 has joined #bitcoin-core-dev
832018-08-09T10:38:18 <jonasschnelli> sipa: I that correct that the Cores existing ChaCha20 implementation is for RNG only? It doesn't do the XORing, right?
842018-08-09T10:58:52 *** csknk has quit IRC
852018-08-09T11:23:44 *** booyah has quit IRC
862018-08-09T11:36:44 *** vicenteH has quit IRC
872018-08-09T11:37:12 *** vicenteH has joined #bitcoin-core-dev
882018-08-09T11:43:14 *** Chris_Stewart_5 has quit IRC
892018-08-09T11:51:02 *** d9b4bef9 has quit IRC
902018-08-09T11:52:08 *** d9b4bef9 has joined #bitcoin-core-dev
912018-08-09T11:56:58 *** tryphe has joined #bitcoin-core-dev
922018-08-09T11:59:52 *** tryphe_ has quit IRC
932018-08-09T12:01:57 *** fanquake has quit IRC
942018-08-09T12:22:45 *** SopaXorzTaker has quit IRC
952018-08-09T12:34:48 *** Victorsueca has quit IRC
962018-08-09T12:35:35 *** fanquake has joined #bitcoin-core-dev
972018-08-09T12:35:57 *** Victorsueca has joined #bitcoin-core-dev
982018-08-09T12:51:02 *** fanquake has quit IRC
992018-08-09T13:03:38 *** arubi has quit IRC
1002018-08-09T13:04:31 *** arubi has joined #bitcoin-core-dev
1012018-08-09T13:11:19 *** provoostenator has quit IRC
1022018-08-09T13:20:21 *** vicenteH has quit IRC
1032018-08-09T13:22:38 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1042018-08-09T13:25:28 *** vicenteH has joined #bitcoin-core-dev
1052018-08-09T13:32:26 *** csknk has joined #bitcoin-core-dev
1062018-08-09T13:46:06 *** provoostenator has joined #bitcoin-core-dev
1072018-08-09T13:51:30 *** provoostenator has quit IRC
1082018-08-09T13:57:02 *** provoostenator has joined #bitcoin-core-dev
1092018-08-09T14:00:57 *** opdenkamp has quit IRC
1102018-08-09T14:04:02 *** provoostenator has quit IRC
1112018-08-09T14:04:12 *** provoost- has joined #bitcoin-core-dev
1122018-08-09T14:04:23 *** provoost- is now known as provoostenator
1132018-08-09T14:05:55 *** opdenkamp has joined #bitcoin-core-dev
1142018-08-09T14:10:30 *** masonicboom has joined #bitcoin-core-dev
1152018-08-09T14:14:51 *** masonicboom has quit IRC
1162018-08-09T14:16:43 *** ExtraCrispy has joined #bitcoin-core-dev
1172018-08-09T14:36:40 *** csknk has quit IRC
1182018-08-09T14:45:04 *** schmidty has quit IRC
1192018-08-09T14:46:05 *** jhfrontz has joined #bitcoin-core-dev
1202018-08-09T14:54:00 *** michaelsdunn1 has joined #bitcoin-core-dev
1212018-08-09T15:01:09 *** jhfrontz has quit IRC
1222018-08-09T15:01:48 <gmaxwell> sipa: results from running 13907?
1232018-08-09T15:13:16 <pierre_rochard> Hello, if anyone here has done a clang AST dump of the project, what command did you use? I'm interested in using python with libclang to traverse the AST
1242018-08-09T15:14:28 <pierre_rochard> I've tried export CXXFLAGS="$CXXFLAGS -ast-dump" && make, to no effect, not sure if I'm going down the wrong rabbit hole and google doesn't have salient results
1252018-08-09T15:16:47 <pierre_rochard> searching the repo turned up this recent comment from skeees https://github.com/bitcoin/bitcoin/pull/13815#issuecomment-409795628 which makes it sound like a material undertaking
1262018-08-09T15:30:30 *** Krellan has quit IRC
1272018-08-09T15:31:35 *** Krellan has joined #bitcoin-core-dev
1282018-08-09T15:53:19 *** harrigan has quit IRC
1292018-08-09T15:53:40 *** goatpig has joined #bitcoin-core-dev
1302018-08-09T15:59:24 *** masonicboom has joined #bitcoin-core-dev
1312018-08-09T16:03:21 *** masonicboom has quit IRC
1322018-08-09T16:07:27 *** Dizzle has joined #bitcoin-core-dev
1332018-08-09T16:27:47 *** Victorsueca has quit IRC
1342018-08-09T16:28:57 *** Victorsueca has joined #bitcoin-core-dev
1352018-08-09T16:33:51 *** jhfrontz has joined #bitcoin-core-dev
1362018-08-09T16:42:30 *** phwalkr has joined #bitcoin-core-dev
1372018-08-09T16:53:38 *** masonicboom has joined #bitcoin-core-dev
1382018-08-09T16:57:45 *** masonicboom has quit IRC
1392018-08-09T17:00:40 *** Krellan has quit IRC
1402018-08-09T17:05:03 <wumpus> pierre_rochard: I did some analysis of the bitcoin source using clang a long time ago, using the python clang bindings (clang.cindex)
1412018-08-09T17:05:37 <wumpus> hooking any kind of analysis tool in the build system is a pain, so I manually provided include paths and such
1422018-08-09T17:05:43 <pierre_rochard> wumpus: that's what I was hoping to use, after reading through this guide https://eli.thegreenplace.net/2011/07/03/parsing-c-in-python-with-clang
1432018-08-09T17:05:46 <pierre_rochard> ah I see
1442018-08-09T17:05:51 *** phwalkr has quit IRC
1452018-08-09T17:08:45 <wumpus> cindex doesn't need it (it can parse on the fly through the API), but to add an analysis tool into the build system one way to do so is by creating a compiler wrapper that outputs both normal output and the metadata output (ast, bitcode, stats, etc). If it doesn't do the former it will fail when trying to link.
1462018-08-09T17:09:01 <wumpus> I don't know if there's an official autotools-supported way
1472018-08-09T17:09:21 <wumpus> like "call this tool as if you'd be calling a C/C++ compiler but don't touch the output"
1482018-08-09T17:10:17 <wumpus> yes, that idea
1492018-08-09T17:11:13 <pierre_rochard> ok in that case I'll try my hand at using cindex directly, instead of doing an ast dump and parsing that
1502018-08-09T17:12:26 <wumpus> might be I even used the same guide :)
1512018-08-09T17:12:49 <wumpus> yes, that's easier, I think, certainly initially
1522018-08-09T17:16:43 *** masonicboom has joined #bitcoin-core-dev
1532018-08-09T17:24:26 <gmaxwell> sipa: grep logs!
1542018-08-09T17:24:55 <sipa> jonasschnelli: right
1552018-08-09T17:25:41 *** elkalamar has joined #bitcoin-core-dev
1562018-08-09T17:39:27 *** masonicboom has quit IRC
1572018-08-09T17:42:06 *** booyah has joined #bitcoin-core-dev
1582018-08-09T17:42:18 <sipa> gmaxwell: no 'locator' message in my log
1592018-08-09T17:44:02 <gmaxwell> hurrah.
1602018-08-09T17:44:10 <gmaxwell> sipa: you have net logging enabled, right?
1612018-08-09T17:45:14 *** masonicboom has joined #bitcoin-core-dev
1622018-08-09T17:45:32 <sipa> gmaxwell: oh, no
1632018-08-09T17:46:00 <sipa> -log=net ?
1642018-08-09T17:46:30 <sipa> oh, -debug=net
1652018-08-09T17:46:53 <gmaxwell> Right
1662018-08-09T17:50:27 <pierre_rochard> wumpus: got cindex working directly, thank you!
1672018-08-09T17:54:27 *** vicenteH has quit IRC
1682018-08-09T17:58:55 <wumpus> pierre_rochard: awesome
1692018-08-09T18:02:08 *** Chatturga has joined #bitcoin-core-dev
1702018-08-09T18:02:22 *** timothy has quit IRC
1712018-08-09T18:16:35 *** Dizzle has quit IRC
1722018-08-09T18:29:05 <achow101> it seems like travis isn't triggering for some PRs
1732018-08-09T18:37:39 <wumpus> which one?
1742018-08-09T18:42:18 *** farmerwampum has joined #bitcoin-core-dev
1752018-08-09T18:45:11 *** elkalamar has left #bitcoin-core-dev
1762018-08-09T18:45:42 *** Taek has quit IRC
1772018-08-09T18:50:46 *** Murch has joined #bitcoin-core-dev
1782018-08-09T18:54:38 *** csknk has joined #bitcoin-core-dev
1792018-08-09T18:55:16 *** promag has joined #bitcoin-core-dev
1802018-08-09T18:55:50 *** clarkmoody has joined #bitcoin-core-dev
1812018-08-09T19:01:12 <sipa> meetung?
1822018-08-09T19:02:24 <luke-jr> hi
1832018-08-09T19:02:36 <instagibbs> #meeting
1842018-08-09T19:02:47 <gmaxwell> Hi.
1852018-08-09T19:02:47 <provoostenator> hi
1862018-08-09T19:02:53 *** schmidty has joined #bitcoin-core-dev
1872018-08-09T19:03:36 <jnewbery> hi
1882018-08-09T19:04:18 <achow101> hi
1892018-08-09T19:04:30 <meshcollider> Is wumpus here?
1902018-08-09T19:04:47 <gmaxwell> now we must hunt the wumpus
1912018-08-09T19:04:55 <Chatturga> hello
1922018-08-09T19:05:11 <sipa> i'll act as pseudowumpus
1932018-08-09T19:05:13 <sipa> #startmeeting
1942018-08-09T19:05:13 <lightningbot> Meeting started Thu Aug 9 19:05:13 2018 UTC. The chair is sipa. Information about MeetBot at http://wiki.debian.org/MeetBot.
1952018-08-09T19:05:13 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
1962018-08-09T19:05:22 <sipa> topics?
1972018-08-09T19:06:16 <sipa> we still have quite a few PRs marked 0.17
1982018-08-09T19:06:36 <sipa> should we discuss low-R sigs?
1992018-08-09T19:07:03 <achow101> +1
2002018-08-09T19:07:08 <jonasschnelli> hi
2012018-08-09T19:07:11 <meshcollider> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
2022018-08-09T19:07:17 <meshcollider> hi
2032018-08-09T19:07:20 <jnewbery> 01:59 < aj> wumpus: in case i'm not awake for the meeting, topic suggestion: lower tx fees, pr #13922 :)
2042018-08-09T19:07:21 <meshcollider> +1
2052018-08-09T19:07:22 <gribble> https://github.com/bitcoin/bitcoin/issues/13922 | Lower default relay fees by ajtowns · Pull Request #13922 · bitcoin/bitcoin · GitHub
2062018-08-09T19:08:17 <sipa> perhaps first let's ask around if there are things for 0.17 that deserve the milestone
2072018-08-09T19:09:17 <sipa> i guess that's a no
2082018-08-09T19:09:22 <sipa> #topic low-r signatures
2092018-08-09T19:09:35 <Murch> hi
2102018-08-09T19:09:40 <sipa> pull request #13666
2112018-08-09T19:09:43 <gribble> https://github.com/bitcoin/bitcoin/issues/13666 | Always create signatures with Low R values by achow101 · Pull Request #13666 · bitcoin/bitcoin · GitHubAsset 1Asset 1
2122018-08-09T19:09:46 <wumpus> ohh sorry!
2132018-08-09T19:10:06 <luke-jr> wumpus: too late, you're fired :p
2142018-08-09T19:10:17 <wumpus> luke-jr: :p
2152018-08-09T19:10:38 <sipa> one issue with the approach is that we need to guess whether signatures created by other software will be assumed to be 71 bytes as well
2162018-08-09T19:10:49 <sipa> as brought up by wumpus in the PR
2172018-08-09T19:11:05 <sipa> (for size estimation purposes)
2182018-08-09T19:11:17 <wumpus> yes the size estimation is the only controversial part there imo
2192018-08-09T19:11:29 <achow101> this is only a problem when we select watching-only inputs
2202018-08-09T19:11:29 <sipa> as we're getting closer to branching off, i wonder if we shouldn't just punt on that
2212018-08-09T19:11:32 <wumpus> obviously it's better to generate smaller signatures where possible
2222018-08-09T19:11:52 <gmaxwell> well we could easily make the size estimate 71 for our keys, and 72 otherwise, and worry about the difference later.
2232018-08-09T19:11:58 <sipa> achow101's code right now will assume 71 byte signatures if we have the keys for everything, and 72 in any other case
2242018-08-09T19:12:12 <Murch> That seems safe.
2252018-08-09T19:12:12 <wumpus> that heuristic makes sense I think
2262018-08-09T19:12:17 <gmaxwell> that seems reasonable enough.
2272018-08-09T19:12:34 <gmaxwell> even if we always estimated 72, I'd rather make the smaller signatures.
2282018-08-09T19:12:43 <wumpus> exactly, it's kind-of independent
2292018-08-09T19:12:51 <sipa> yes, i don't think the discussion is about whether or not to produce 71 byte signatures
2302018-08-09T19:12:56 <sipa> we should always do so
2312018-08-09T19:13:05 <achow101> imo estimating 72 bytes kind of defeats the purpose of producing 71 byte sigs
2322018-08-09T19:13:15 <Murch> it doesn't
2332018-08-09T19:13:17 <wumpus> it still takes less space in the block chain.
2342018-08-09T19:13:18 <gmaxwell> achow101: might defeat _your_ purpose. :P
2352018-08-09T19:13:22 <luke-jr> achow101: nah, you get value in feerate
2362018-08-09T19:13:28 <Murch> You're still getting a higher effective fee rate and block space savings
2372018-08-09T19:13:30 <wumpus> and you get better feerate, yep
2382018-08-09T19:13:39 <gmaxwell> what wumpus said. it still economizes use of a public resource, and you still get higher priority.
2392018-08-09T19:14:06 <sipa> in any case,
2402018-08-09T19:14:10 <sipa> #action review 13666
2412018-08-09T19:14:22 <sipa> it adds a bit of complexity by adding a second dummy signer
2422018-08-09T19:14:27 <Murch> might save some 3kB per block or so.
2432018-08-09T19:14:39 <Murch> If everyone did it
2442018-08-09T19:15:16 <wumpus> yes
2452018-08-09T19:15:33 * luke-jr wonders if we should look into getting rid of the Segwit dummy/flags too
2462018-08-09T19:15:35 <provoostenator> You can always add a param to the RPC that says "assume 71 "
2472018-08-09T19:15:42 *** csknk has quit IRC
2482018-08-09T19:15:48 <luke-jr> ofc that doesn't affect the consensus limits, so not incentivised :/
2492018-08-09T19:16:08 <sipa> well, thinking ahead, we may need that anyway - in case more complicated scripts are supported, the size may depend on what subset of signers is present
2502018-08-09T19:16:16 <sipa> but that seems too late for 0.17
2512018-08-09T19:16:24 <wumpus> provoostenator: I'm... not sure it's good to add such little implementation details to RPC, but maybe a more general fee estimation strategy can be exposed such way
2522018-08-09T19:16:34 <wumpus> yes, definitely
2532018-08-09T19:16:43 <provoostenator> Luckily the RPC is experimental
2542018-08-09T19:16:47 <gmaxwell> rpc would be a bad place for it
2552018-08-09T19:16:52 <sipa> or rather, we may need to add a way to pass in information about other signers to transaction creation RPS
2562018-08-09T19:16:55 <sipa> RPCs
2572018-08-09T19:16:59 <Murch> @provoostenator: I don't think that there is sufficient use of multi party transactions and savings to add a param for that.
2582018-08-09T19:17:01 <gmaxwell> the right place would be as metadata on the keys/outputs in the wallet.
2592018-08-09T19:17:12 <sipa> gmaxwell: how so?
2602018-08-09T19:17:22 <sipa> ah yes, but the 71/72 thing - agree
2612018-08-09T19:17:29 *** jhfrontz has quit IRC
2622018-08-09T19:18:23 <sipa> luke-jr: i don't know what you're referring to?
2632018-08-09T19:18:24 <gmaxwell> sipa: just that the size of an scriptpubkey's signature is just a property of the private key(s).
2642018-08-09T19:18:34 <sipa> gmaxwell: yes, indeed
2652018-08-09T19:18:40 <gmaxwell> just like the pubkey part of the scriptsig being 65 or 33 bytes.
2662018-08-09T19:19:57 <sipa> do we have other topics?
2672018-08-09T19:20:01 <gmaxwell> in any case, for now its fine to just assume 72 unless we know otherwise. In the future we can be smarter.
2682018-08-09T19:20:14 <Murch> the problem will be permanently solved by the new signature encoding that is proposed for Schnorr signatures anyway.
2692018-08-09T19:20:18 <luke-jr> sipa: just that the dummy 2 bytes in every Segwit tx could be eliminated on the network/disk level, if we're trying to focus on micro-optimisations of space
2702018-08-09T19:20:21 *** masonicboom has quit IRC
2712018-08-09T19:20:39 <gmaxwell> luke-jr: far far better than that can be done.
2722018-08-09T19:20:51 <sipa> luke-jr: sure; and much more than that, we should look into compressing all data on the wire
2732018-08-09T19:20:58 <sipa> we have someone looking into that
2742018-08-09T19:21:05 <meshcollider> You had a whole write-up on a compressed transaction format earlier didn't you
2752018-08-09T19:21:23 <sipa> meshcollider: yes, there's a bunch of improvements and simplifications
2762018-08-09T19:21:27 <sipa> which we haven't published
2772018-08-09T19:21:46 <sipa> 19:07:19 < jnewbery> 01:59 < aj> wumpus: in case i'm not awake for the meeting, topic suggestion: lower tx fees, pr #13922 :)
2782018-08-09T19:21:48 <gribble> https://github.com/bitcoin/bitcoin/issues/13922 | Lower default relay fees by ajtowns · Pull Request #13922 · bitcoin/bitcoin · GitHub
2792018-08-09T19:21:55 <sipa> #topic lower tx fees, pr 13922
2802018-08-09T19:22:30 <Murch> "it changes the min tx fee to 200 s/B, and the incremental relay fee to 100 s/B" doesn't he mean s/kB?
2812018-08-09T19:22:48 *** Krellan has joined #bitcoin-core-dev
2822018-08-09T19:22:53 <gmaxwell> and is that kVB not B?
2832018-08-09T19:23:07 <jnewbery> (I don't have any input on this topic except to concept ACK the PR. Only relaying aj's earlier message)
2842018-08-09T19:23:07 <Murch> yeah, kvB
2852018-08-09T19:23:44 <gmaxwell> I feel pretty meh about dropping feerates. I guess 200 isn't that much of a change but at some level we get back in spamflood level land.
2862018-08-09T19:23:57 <sipa> i have no opinion on this topic
2872018-08-09T19:24:18 <luke-jr> it's low enough I don't care; I'd prefer to see users adopt changes manually rather than top-down default modifications, but meh
2882018-08-09T19:24:31 <Murch> gmaxwell: I think that reducing the fee could drive some UTXO consolidation
2892018-08-09T19:24:52 <gmaxwell> or cause waiting until it's dropped further.
2902018-08-09T19:25:04 <luke-jr> Murch: if that's the goal, maybe it should explicitly look for that
2912018-08-09T19:25:43 <Murch> I've observed that time preference signaling has improved a lot this year. One of our customers explicitly waited for us to allow a fee rate of 2 sats/B before consolidating.
2922018-08-09T19:26:05 <Murch> If 0.2 sats/B were possible, I'd not be surprised to see some more of that.
2932018-08-09T19:27:23 <gmaxwell> Well lets try it, but if things go wonky it can be set back.
2942018-08-09T19:27:34 <Murch> We do have small fee spikes every now and then again. I think that we'd get a backlog of consolidations at least part of the time, hopefully consistently in the future.
2952018-08-09T19:27:56 <Murch> The biggest issue is that most miners don't mine anything below 1 sats/B
2962018-08-09T19:28:14 <gmaxwell> in terms of the patch, I'm not sure it's doing it correctly as is. Basically we must lower relay and mining behavior before wallet... changing the estimator to allow low estimates before we know they reliably propagate will cause stuck users.
2972018-08-09T19:28:21 <Murch> (showing as a solid backlog below 1 sat/B, even when blocks have space left)
2982018-08-09T19:28:34 <luke-jr> Murch: well, if that's the case, it would be bad to drop relay fees lower
2992018-08-09T19:28:59 <Murch> I don't follow.
3002018-08-09T19:29:08 <gmaxwell> luke-jr: the theory is if the defaults change the behavior will too.
3012018-08-09T19:29:08 <sipa> luke-jr: i'm sure miners don't allow below 1 vsat/B _because_ the network doesn't relay them
3022018-08-09T19:29:36 <Murch> Ah I see.
3032018-08-09T19:29:40 <gmaxwell> Murch: luke's point is that we shouldn't be relaying things that won't get mined.
3042018-08-09T19:29:51 <Murch> Yeah, miners tend to lag behind on adoption of new versions
3052018-08-09T19:30:10 <luke-jr> has anyone discussed this with any miners?
3062018-08-09T19:30:18 <Murch> It would already help if we found a few percent of the hash rate that tells us they would support it
3072018-08-09T19:30:34 <luke-jr> Murch: this is a matter of policy, not versions. defaults are just defaults.
3082018-08-09T19:30:41 <sipa> so 1) reduce the minimum feerate the mining code works at 2) if/when that gets adopted, start relaying below 1 3) if/when that gets adopted, make fee estimation work with it
3092018-08-09T19:30:59 <Murch> My suspicion is that most miners don't much fiddle with defaults.
3102018-08-09T19:31:31 <Murch> seems like a reasonable order of things
3112018-08-09T19:32:00 <luke-jr> Murch: they should. this is their job, not developers'
3122018-08-09T19:32:30 <gmaxwell> can we not have this debate here and now.
3132018-08-09T19:32:34 <provoostenator> My main concern with allowing sub 1 satoshi / vbyte fees is that - when fees are low - there's going to be a good chance the users transaction doesn't propagate.
3142018-08-09T19:32:37 <gmaxwell> it's really tedious.
3152018-08-09T19:32:46 <Murch> luke-jr: IF they were engaging at that level of the technology, they wouldn't be running mining operations of RaspberryPis, lag behind multiple versions causing orphans, and similar things.
3162018-08-09T19:33:13 <gmaxwell> provoostenator: that was my comment above, relay/mining behavior needs to change ahead of wallet behavior, they can't both change at once.
3172018-08-09T19:34:09 <provoostenator> gmaxwell: ah I see, by keeping the wallet minimum at 1 sat / byte, that makes sense.
3182018-08-09T19:34:11 <phantomcircuit> gmaxwell, mining needs to change, then relay, then wallet
3192018-08-09T19:34:19 <phantomcircuit> but none of the first two have a reason to change without the later
3202018-08-09T19:34:20 <phantomcircuit> sooo
3212018-08-09T19:34:21 <achow101> gmaxwell: so at best, this would need to be deployed across two versions
3222018-08-09T19:34:39 <gmaxwell> achow101: yes.
3232018-08-09T19:34:41 <wumpus> at least
3242018-08-09T19:34:47 <achow101> which means, at this point, it's a year and a half out
3252018-08-09T19:34:59 <achow101> and by then, who knows what fees will be like
3262018-08-09T19:34:59 <luke-jr> they can be minor versions
3272018-08-09T19:35:00 <phantomcircuit> achow101, and realistically miners do change the defaults so...
3282018-08-09T19:35:01 <wumpus> it depends, we can see the adoption
3292018-08-09T19:35:30 <wumpus> and decide when (if ever) the wallet part can go in
3302018-08-09T19:35:32 <gmaxwell> as luke-jr says. also users can locally override their wallets once they know that lower rates will confirm.
3312018-08-09T19:35:37 <wumpus> yes
3322018-08-09T19:35:59 <gmaxwell> phantomcircuit: we can handle some things getting relayed that don't get mined at least... (now, not so much years ago)
3332018-08-09T19:36:07 <Murch> phantomcircuit: It's enough if a portion of the hashrate adopts the change to make it's use a viable strategy for low time-preference txes.
3342018-08-09T19:37:04 <Murch> Talking to miners would be a good idea
3352018-08-09T19:37:39 <gmaxwell> I'd really like it if there wouldn't need to be these thresholds at all, but unfortunately, solving making it all automatic seems excessively hard.
3362018-08-09T19:38:14 <gmaxwell> In any case, I'd review and ack a split up that moved the relay/mining defaults and left the wallet parts up for a later version.
3372018-08-09T19:40:45 <sipa> any other topics?
3382018-08-09T19:40:46 <Murch> So, pseudowumpus sipa, anything else on your agenda?
3392018-08-09T19:41:04 <luke-jr> gmaxwell: I thought the current PR already left wallet alone
3402018-08-09T19:41:09 <phantomcircuit> gmaxwell, automating all these levels would be vastly simplified by efficient mempool sync
3412018-08-09T19:41:13 <gmaxwell> luke-jr: ah, haven't checked.
3422018-08-09T19:41:14 <phantomcircuit> which im sure you know :P
3432018-08-09T19:41:36 <sipa> phantomcircuit: you can't automate the decision on incremental relay feerate
3442018-08-09T19:41:45 <sipa> as it's not mempool dependent but bandwidth cost dependent
3452018-08-09T19:42:47 <sipa> wumpus: you have any other topics?
3462018-08-09T19:43:00 <luke-jr> sipa: not your own nodes cost directly, though? since you're not getting paid for it; so measuring bandwidth availability may be sufficient?
3472018-08-09T19:43:42 <wumpus> nope!
3482018-08-09T19:43:43 <sipa> luke-jr: if you'd set it to 0, you can be pushed into arbitrarily high bandwidth usage by an attacker
3492018-08-09T19:43:50 <wumpus> the 0.17 list basically
3502018-08-09T19:44:17 <gmaxwell> luke-jr: for incremental, it's relatively important that the behavior be consistent. Thats largely at odds with automating it, unfortunately.
3512018-08-09T19:44:36 <sipa> yeah, let's just take further discussion to the individual PRs
3522018-08-09T19:44:38 <sipa> #endmeeting
3532018-08-09T19:44:38 <lightningbot> Meeting ended Thu Aug 9 19:44:38 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
3542018-08-09T19:44:38 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-08-09-19.05.html
3552018-08-09T19:44:38 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-08-09-19.05.txt
3562018-08-09T19:44:38 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-08-09-19.05.log.html
3572018-08-09T19:44:49 <wumpus> #13808 certainly needs more review
3582018-08-09T19:44:50 <gribble> https://github.com/bitcoin/bitcoin/issues/13808 | wallet: shuffle coins before grouping, where warranted by kallewoof · Pull Request #13808 · bitcoin/bitcoin · GitHub
3592018-08-09T19:44:52 <luke-jr> sipa: right, but if you set it to some formula based on measured bandwidth available..
3602018-08-09T19:45:17 <wumpus> if not, I'd be inclined to postpone it
3612018-08-09T19:45:49 <gmaxwell> luke-jr: measuring bandwidth is basically intractable. :)
3622018-08-09T19:46:47 <luke-jr> gmaxwell: could also query the network router for that info in theory
3632018-08-09T19:47:37 <gmaxwell> which is will virtually never know...
3642018-08-09T19:47:37 <sipa> and your ISP's cost, and the bitcoin exchange rate?
3652018-08-09T19:48:08 <luke-jr> sipa: you're not receiving the tx fee, so just a general cost estimate should be good enough I would think?
3662018-08-09T19:48:34 *** masonicboom has joined #bitcoin-core-dev
3672018-08-09T19:48:55 <luke-jr> maybe not perfect, but probably better than manually adjusting defaults on the current level
3682018-08-09T19:50:52 <gmaxwell> sipa: so, now that you're logging right, any results?
3692018-08-09T19:51:21 <sipa> 2018-08-09T18:55:00.534227Z getblocks locator size 101 > 64, disconnect peer=414
3702018-08-09T19:52:41 <sipa> 2018-08-09T18:55:00.301077Z receive version message: /bitcoinj:0.14.7/Bitcoin Wallet:6.28/: version 70001, blocks=535894, us=127.0.0.1:8333, peer=414
3712018-08-09T19:54:16 <gmaxwell> So, as evoskuil said, 101 though.. not 100. Moronic behavior. So, should I just back the PR off to 101?
3722018-08-09T19:58:53 *** promag has quit IRC
3732018-08-09T19:59:40 *** jhfrontz has joined #bitcoin-core-dev
3742018-08-09T20:02:13 *** Murch has quit IRC
3752018-08-09T20:07:40 *** jhfrontz has quit IRC
3762018-08-09T20:07:56 *** csknk has joined #bitcoin-core-dev
3772018-08-09T20:15:03 *** jhfrontz has joined #bitcoin-core-dev
3782018-08-09T20:23:02 *** jhfrontz has quit IRC
3792018-08-09T20:24:15 *** jhfrontz has joined #bitcoin-core-dev
3802018-08-09T20:28:10 *** jhfrontz has quit IRC
3812018-08-09T20:29:10 *** Chatturga has quit IRC
3822018-08-09T20:34:45 *** jhfrontz has joined #bitcoin-core-dev
3832018-08-09T20:35:38 *** Murch has joined #bitcoin-core-dev
3842018-08-09T20:45:06 *** Murch has quit IRC
3852018-08-09T20:49:05 *** Chris_Stewart_5 has quit IRC
3862018-08-09T20:52:40 *** jhfrontz has quit IRC
3872018-08-09T20:55:40 *** jhfrontz has joined #bitcoin-core-dev
3882018-08-09T20:58:52 *** jb55 has joined #bitcoin-core-dev
3892018-08-09T21:01:32 *** clarkmoody has quit IRC
3902018-08-09T21:09:37 *** Murchone has joined #bitcoin-core-dev
3912018-08-09T21:09:43 *** Murchone has quit IRC
3922018-08-09T21:11:44 *** michaelsdunn1 has quit IRC
3932018-08-09T21:12:56 *** csknk has quit IRC
3942018-08-09T21:24:30 *** Murch has joined #bitcoin-core-dev
3952018-08-09T21:24:46 *** Murch has quit IRC
3962018-08-09T21:25:52 *** Murch has joined #bitcoin-core-dev
3972018-08-09T21:45:59 *** Murch has quit IRC
3982018-08-09T21:49:06 *** Murch has joined #bitcoin-core-dev
3992018-08-09T21:50:45 *** Murch has quit IRC
4002018-08-09T21:51:43 *** Murch has joined #bitcoin-core-dev
4012018-08-09T21:57:28 *** roshii has joined #bitcoin-core-dev
4022018-08-09T21:59:57 *** arubi has quit IRC
4032018-08-09T22:00:25 *** arubi has joined #bitcoin-core-dev
4042018-08-09T22:00:36 *** Murch has quit IRC
4052018-08-09T22:02:48 *** Guyver2 has quit IRC
4062018-08-09T22:19:02 *** Murch has joined #bitcoin-core-dev
4072018-08-09T22:20:11 <gmaxwell> [ot, an outright backdoor in VIA C3 cpu] https://github.com/xoreaxeaxeax/rosenbridge
4082018-08-09T22:32:40 *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
4092018-08-09T22:38:42 *** vicenteH has joined #bitcoin-core-dev
4102018-08-09T22:41:51 *** masonicboom has quit IRC
4112018-08-09T22:43:54 *** masonicboom has joined #bitcoin-core-dev
4122018-08-09T22:52:43 *** Cogito_Ergo_Sum has quit IRC
4132018-08-09T23:10:48 *** justanotheruser has quit IRC
4142018-08-09T23:15:49 *** justanotheruser has joined #bitcoin-core-dev
4152018-08-09T23:25:38 *** Victorsueca has quit IRC
4162018-08-09T23:26:48 *** Victorsueca has joined #bitcoin-core-dev
4172018-08-09T23:49:27 *** justanotheruser has quit IRC
4182018-08-09T23:52:51 *** masonicboom has quit IRC
4192018-08-09T23:53:30 *** goatpig has quit IRC