12019-03-29T00:09:06  *** giesen has joined #bitcoin-core-dev
  22019-03-29T00:15:44  *** redj29 has joined #bitcoin-core-dev
  32019-03-29T00:16:15  *** redj29 has quit IRC
  42019-03-29T00:21:01  <achow101> sipa: how come expanding a descriptor returns a vector of scriptPubKeys? Isn't there only one possible scriptPubKey that a descriptor can return?
  52019-03-29T00:21:20  <sipa> achow101: combo does multiple
  62019-03-29T00:21:35  <achow101> ah, so that's the only descriptor that can have multiple?
  72019-03-29T00:21:47  <sipa> at a single position, yes
  82019-03-29T00:22:02  <sipa> for now (though i don't think there is any good reason to add more)
  92019-03-29T00:26:55  *** murchandamus has joined #bitcoin-core-dev
 102019-03-29T00:29:15  *** tyldis23 has joined #bitcoin-core-dev
 112019-03-29T00:33:28  *** Kvaciral has quit IRC
 122019-03-29T00:36:55  *** promag has quit IRC
 132019-03-29T01:10:04  *** jarthur has quit IRC
 142019-03-29T01:17:04  *** zhangzf has joined #bitcoin-core-dev
 152019-03-29T01:20:07  *** d1b15 has joined #bitcoin-core-dev
 162019-03-29T01:20:33  *** d1b15 has quit IRC
 172019-03-29T01:22:25  *** sipa has quit IRC
 182019-03-29T01:26:30  *** kee7a_5 has joined #bitcoin-core-dev
 192019-03-29T01:27:38  *** sipa has joined #bitcoin-core-dev
 202019-03-29T01:36:36  *** Krellan has quit IRC
 212019-03-29T01:41:24  *** EagleTM has quit IRC
 222019-03-29T01:56:32  *** mountaingoat20 has joined #bitcoin-core-dev
 232019-03-29T01:56:44  *** spinza has quit IRC
 242019-03-29T02:27:13  *** spinza has joined #bitcoin-core-dev
 252019-03-29T02:27:33  *** captjakk has joined #bitcoin-core-dev
 262019-03-29T02:30:02  *** ExtraCrispy has quit IRC
 272019-03-29T02:30:32  *** ExtraCrispy has joined #bitcoin-core-dev
 282019-03-29T02:31:42  *** captjakk has quit IRC
 292019-03-29T02:33:35  *** captjakk has joined #bitcoin-core-dev
 302019-03-29T02:37:34  *** promag has joined #bitcoin-core-dev
 312019-03-29T02:42:12  *** promag has quit IRC
 322019-03-29T03:08:09  *** roconnor has quit IRC
 332019-03-29T03:11:07  *** smgoller23 has joined #bitcoin-core-dev
 342019-03-29T03:46:16  *** tryphe has quit IRC
 352019-03-29T03:46:41  *** tryphe has joined #bitcoin-core-dev
 362019-03-29T03:50:32  *** tryphe_ has joined #bitcoin-core-dev
 372019-03-29T03:53:34  *** tryphe has quit IRC
 382019-03-29T04:04:48  *** roconnor has joined #bitcoin-core-dev
 392019-03-29T04:12:52  *** StopAndDecrypt_ has joined #bitcoin-core-dev
 402019-03-29T04:13:23  *** StopAndDecrypt has quit IRC
 412019-03-29T04:29:00  *** glyptographicGoa has joined #bitcoin-core-dev
 422019-03-29T04:33:11  *** glyptographicGoa has quit IRC
 432019-03-29T04:38:59  *** promag has joined #bitcoin-core-dev
 442019-03-29T04:43:25  *** promag has quit IRC
 452019-03-29T04:51:38  *** captjakk has quit IRC
 462019-03-29T04:52:55  *** mildly_risky has joined #bitcoin-core-dev
 472019-03-29T04:53:58  *** mildly_risky has quit IRC
 482019-03-29T04:59:22  *** dviola has quit IRC
 492019-03-29T05:06:07  *** niska has quit IRC
 502019-03-29T05:11:16  *** niska has joined #bitcoin-core-dev
 512019-03-29T05:30:29  *** DeanGuss has joined #bitcoin-core-dev
 522019-03-29T07:31:33  *** Krellan has joined #bitcoin-core-dev
 532019-03-29T07:36:00  *** Krellan has quit IRC
 542019-03-29T07:41:23  *** rex4539 has quit IRC
 552019-03-29T08:10:27  *** zhangzf has quit IRC
 562019-03-29T08:10:54  *** zhangzf has joined #bitcoin-core-dev
 572019-03-29T08:14:04  *** e4xit has quit IRC
 582019-03-29T08:14:52  *** e4xit has joined #bitcoin-core-dev
 592019-03-29T08:20:47  *** niska has quit IRC
 602019-03-29T08:26:18  *** rex4539 has joined #bitcoin-core-dev
 612019-03-29T08:30:31  *** niska has joined #bitcoin-core-dev
 622019-03-29T09:02:19  *** setpill has joined #bitcoin-core-dev
 632019-03-29T09:20:18  *** darosior has joined #bitcoin-core-dev
 642019-03-29T09:23:01  *** bitcoin-git has joined #bitcoin-core-dev
 652019-03-29T09:23:01  <bitcoin-git> [bitcoin] jonasschnelli pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/9e7dc682e0f6...edc68d40e968
 662019-03-29T09:23:02  <bitcoin-git> bitcoin/master f6ee177 practicalswift: Remove unused AES-128 code
 672019-03-29T09:23:02  <bitcoin-git> bitcoin/master edc68d4 Jonas Schnelli: Merge #15663: crypto: Remove unused AES-128 code
 682019-03-29T09:23:15  *** bitcoin-git has left #bitcoin-core-dev
 692019-03-29T09:23:33  *** timothy has joined #bitcoin-core-dev
 702019-03-29T09:23:55  *** bitcoin-git has joined #bitcoin-core-dev
 712019-03-29T09:23:55  <bitcoin-git> [bitcoin] jonasschnelli merged pull request #15663: crypto: Remove unused AES-128 code (master...aes-128) https://github.com/bitcoin/bitcoin/pull/15663
 722019-03-29T09:23:58  *** bitcoin-git has left #bitcoin-core-dev
 732019-03-29T09:39:45  *** Zenton has joined #bitcoin-core-dev
 742019-03-29T10:07:26  *** DeanGuss has quit IRC
 752019-03-29T10:07:53  *** DeanGuss has joined #bitcoin-core-dev
 762019-03-29T10:18:49  *** spinza has quit IRC
 772019-03-29T10:24:55  *** spinza has joined #bitcoin-core-dev
 782019-03-29T10:42:16  *** rex4539 has quit IRC
 792019-03-29T10:45:05  *** internetworm is now known as badcc
 802019-03-29T10:45:08  *** badcc is now known as badccvoid
 812019-03-29T10:47:07  *** badccvoid has left #bitcoin-core-dev
 822019-03-29T10:48:08  *** badccvoid has joined #bitcoin-core-dev
 832019-03-29T10:58:21  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 842019-03-29T11:08:52  *** zhangzf has quit IRC
 852019-03-29T11:29:19  *** tryphe_ has quit IRC
 862019-03-29T11:29:46  *** tryphe_ has joined #bitcoin-core-dev
 872019-03-29T11:45:09  *** jonatack has joined #bitcoin-core-dev
 882019-03-29T11:52:43  *** darosior has quit IRC
 892019-03-29T11:59:32  *** Deacyde has joined #bitcoin-core-dev
 902019-03-29T12:14:12  *** jb55 has quit IRC
 912019-03-29T12:15:28  *** shesek has quit IRC
 922019-03-29T12:24:16  *** spinza has quit IRC
 932019-03-29T12:27:13  *** zhangzf has joined #bitcoin-core-dev
 942019-03-29T12:31:03  *** zhangzf has quit IRC
 952019-03-29T12:38:29  *** promag has joined #bitcoin-core-dev
 962019-03-29T12:39:48  *** spinza has joined #bitcoin-core-dev
 972019-03-29T12:41:20  *** jb55 has joined #bitcoin-core-dev
 982019-03-29T12:42:52  *** promag has quit IRC
 992019-03-29T12:45:52  *** promag has joined #bitcoin-core-dev
1002019-03-29T12:46:39  *** rex4539 has joined #bitcoin-core-dev
1012019-03-29T12:46:39  *** promag has quit IRC
1022019-03-29T12:55:26  *** spaced0ut has joined #bitcoin-core-dev
1032019-03-29T13:09:12  *** Soligor has quit IRC
1042019-03-29T13:22:13  *** Soligor has joined #bitcoin-core-dev
1052019-03-29T13:24:19  *** tryphe_ has quit IRC
1062019-03-29T13:24:44  *** tryphe_ has joined #bitcoin-core-dev
1072019-03-29T13:27:36  *** Bullitje has quit IRC
1082019-03-29T13:30:20  *** zhangzf has joined #bitcoin-core-dev
1092019-03-29T14:04:56  *** setpill has quit IRC
1102019-03-29T14:22:10  *** tryphe_ has quit IRC
1112019-03-29T14:22:38  *** tryphe_ has joined #bitcoin-core-dev
1122019-03-29T14:23:13  *** Chris_Stewart_5 has quit IRC
1132019-03-29T14:23:13  *** Guyver2 has joined #bitcoin-core-dev
1142019-03-29T14:28:26  *** badccvoid is now known as asimo3089
1152019-03-29T14:28:29  *** asimo3089 is now known as badcc
1162019-03-29T14:28:34  *** badcc is now known as badccvoid
1172019-03-29T14:34:06  *** saks has joined #bitcoin-core-dev
1182019-03-29T14:41:32  *** shesek has joined #bitcoin-core-dev
1192019-03-29T14:41:32  *** shesek has joined #bitcoin-core-dev
1202019-03-29T14:42:14  <gkrizek> Could I get perhaps get another review on #15255. It's just a CI fix, but could probably use another look
1212019-03-29T14:42:16  <gribble> https://github.com/bitcoin/bitcoin/issues/15255 | [tests] Remove travis_wait from lint script by gkrizek · Pull Request #15255 · bitcoin/bitcoin · GitHub
1222019-03-29T14:49:59  *** zhangzf has quit IRC
1232019-03-29T14:53:40  *** shesek has quit IRC
1242019-03-29T14:54:30  *** EagleTM has joined #bitcoin-core-dev
1252019-03-29T14:55:38  *** jonatack has quit IRC
1262019-03-29T14:59:03  *** badccvoid is now known as badccv
1272019-03-29T14:59:52  *** promag has joined #bitcoin-core-dev
1282019-03-29T15:08:50  *** EagleTM has quit IRC
1292019-03-29T15:13:58  *** Deadhand has quit IRC
1302019-03-29T15:14:20  *** Deadhand has joined #bitcoin-core-dev
1312019-03-29T15:22:22  *** farmerwampum_ has joined #bitcoin-core-dev
1322019-03-29T15:22:23  *** tryphe_ has quit IRC
1332019-03-29T15:22:34  *** tryphe_ has joined #bitcoin-core-dev
1342019-03-29T15:24:06  *** MarcoFalke has quit IRC
1352019-03-29T15:24:19  *** spinza has quit IRC
1362019-03-29T15:24:22  *** MarcoFalke has joined #bitcoin-core-dev
1372019-03-29T15:24:48  *** Ll1i1lL has quit IRC
1382019-03-29T15:25:08  *** bitcoin-git has joined #bitcoin-core-dev
1392019-03-29T15:25:09  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/edc68d40e968...904129b35dd6
1402019-03-29T15:25:09  <bitcoin-git> bitcoin/master 8b8d8ee Graham Krizek: Remove travis_wait from lint script
1412019-03-29T15:25:10  <bitcoin-git> bitcoin/master 904129b MarcoFalke: Merge #15255: [tests] Remove travis_wait from lint script
1422019-03-29T15:25:12  *** bitcoin-git has left #bitcoin-core-dev
1432019-03-29T15:25:13  *** farmerwampum__ has quit IRC
1442019-03-29T15:25:13  *** luke-jr has quit IRC
1452019-03-29T15:25:18  *** jarthur has joined #bitcoin-core-dev
1462019-03-29T15:25:48  *** bitcoin-git has joined #bitcoin-core-dev
1472019-03-29T15:25:48  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #15255: [tests] Remove travis_wait from lint script (master...remove-travis_wait) https://github.com/bitcoin/bitcoin/pull/15255
1482019-03-29T15:25:53  *** bitcoin-git has left #bitcoin-core-dev
1492019-03-29T15:26:43  *** luke-jr has joined #bitcoin-core-dev
1502019-03-29T15:27:00  *** Ll1i1lL has joined #bitcoin-core-dev
1512019-03-29T15:27:05  *** badccv has quit IRC
1522019-03-29T15:28:18  <gkrizek> Thanks MarcoFalke
1532019-03-29T15:31:50  *** spinza has joined #bitcoin-core-dev
1542019-03-29T15:36:47  *** dermoth has quit IRC
1552019-03-29T15:44:19  *** dermoth has joined #bitcoin-core-dev
1562019-03-29T15:49:45  *** captjakk has joined #bitcoin-core-dev
1572019-03-29T15:52:31  *** dqx_ has joined #bitcoin-core-dev
1582019-03-29T15:54:12  *** captjakk has quit IRC
1592019-03-29T15:57:38  *** lnostdal has quit IRC
1602019-03-29T15:57:53  *** lnostdal has joined #bitcoin-core-dev
1612019-03-29T16:00:34  *** captjakk has joined #bitcoin-core-dev
1622019-03-29T16:16:22  *** justanotheruser has quit IRC
1632019-03-29T16:18:10  *** Urgo has joined #bitcoin-core-dev
1642019-03-29T16:27:05  *** jnewbery has joined #bitcoin-core-dev
1652019-03-29T16:44:38  *** qu4ku has joined #bitcoin-core-dev
1662019-03-29T17:00:56  *** lnostdal has quit IRC
1672019-03-29T17:01:22  *** adiabat has quit IRC
1682019-03-29T17:04:00  *** adiabat has joined #bitcoin-core-dev
1692019-03-29T17:05:56  *** lnostdal has joined #bitcoin-core-dev
1702019-03-29T17:20:23  *** Zenton has quit IRC
1712019-03-29T17:21:33  *** bitcoin-git has joined #bitcoin-core-dev
1722019-03-29T17:21:34  <bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/904129b35dd6...dc5c2e440746
1732019-03-29T17:21:35  <bitcoin-git> bitcoin/master 1c29ac4 John Newbery: [tests] style fixes in feature_pruning.py
1742019-03-29T17:21:35  <bitcoin-git> bitcoin/master 03d6d23 John Newbery: [tests] make pruning test faster
1752019-03-29T17:21:36  <bitcoin-git> bitcoin/master dc5c2e4 MarcoFalke: Merge #15686: [tests] make pruning test faster
1762019-03-29T17:21:38  *** bitcoin-git has left #bitcoin-core-dev
1772019-03-29T17:22:10  *** tryphe_ has quit IRC
1782019-03-29T17:22:25  *** bitcoin-git has joined #bitcoin-core-dev
1792019-03-29T17:22:25  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #15686: [tests] make pruning test faster (master...2019_03_faster_pruning_test) https://github.com/bitcoin/bitcoin/pull/15686
1802019-03-29T17:22:37  *** tryphe_ has joined #bitcoin-core-dev
1812019-03-29T17:22:37  *** bitcoin-git has left #bitcoin-core-dev
1822019-03-29T17:23:25  *** bitcoin-git has joined #bitcoin-core-dev
1832019-03-29T17:23:25  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/dc5c2e440746...0baf4b1f9663
1842019-03-29T17:23:26  <bitcoin-git> bitcoin/master 2a1408c Peter Bushnell: Comment for seemingly duplicate LIBBITCOIN_SERVER
1852019-03-29T17:23:26  <bitcoin-git> bitcoin/master 0baf4b1 MarcoFalke: Merge #15683: Comment for seemingly duplicate LIBBITCOIN_SERVER
1862019-03-29T17:23:27  *** owowo has quit IRC
1872019-03-29T17:23:28  *** bitcoin-git has left #bitcoin-core-dev
1882019-03-29T17:24:10  *** bitcoin-git has joined #bitcoin-core-dev
1892019-03-29T17:24:10  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #15683: Comment for seemingly duplicate LIBBITCOIN_SERVER (master...patch-1) https://github.com/bitcoin/bitcoin/pull/15683
1902019-03-29T17:24:11  *** bitcoin-git has left #bitcoin-core-dev
1912019-03-29T17:27:20  *** bitcoin-git has joined #bitcoin-core-dev
1922019-03-29T17:27:20  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #15696: [qa] test_runner: Move feature_pruning to base tests (master...1904-qaPruning) https://github.com/bitcoin/bitcoin/pull/15696
1932019-03-29T17:27:27  *** bitcoin-git has left #bitcoin-core-dev
1942019-03-29T17:27:30  *** jnewbery has quit IRC
1952019-03-29T17:28:45  *** owowo has joined #bitcoin-core-dev
1962019-03-29T17:31:46  *** jnewbery has joined #bitcoin-core-dev
1972019-03-29T17:32:56  *** linksxxx has joined #bitcoin-core-dev
1982019-03-29T17:41:24  *** bitcoin-git has joined #bitcoin-core-dev
1992019-03-29T17:41:24  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #15697: qa: Make swap_magic_bytes in p2p_invalid_messages atomic (master...1904-qaMagicAtomic) https://github.com/bitcoin/bitcoin/pull/15697
2002019-03-29T17:41:34  *** bitcoin-git has left #bitcoin-core-dev
2012019-03-29T18:06:01  *** Sentineo has quit IRC
2022019-03-29T18:13:34  *** obsrver has joined #bitcoin-core-dev
2032019-03-29T18:22:11  *** tryphe_ has quit IRC
2042019-03-29T18:22:36  *** tryphe_ has joined #bitcoin-core-dev
2052019-03-29T18:29:20  *** bitcoin-git has joined #bitcoin-core-dev
2062019-03-29T18:29:20  <bitcoin-git> [bitcoin] practicalswift opened pull request #15699: Remove no-op CClientUIInterface::[signal_name]_disconnect. Disconnect BlockNotifyGenesisWait and RPCNotifyBlockChange properly. (master...remove-CClientUIInterface-signal_name_disconnect) https://github.com/bitcoin/bitcoin/pull/15699
2072019-03-29T18:29:21  *** bitcoin-git has left #bitcoin-core-dev
2082019-03-29T18:31:55  <meshcollider> Apologies, I'm travelling to Portugal for ICPC at the moment so my timezone is completely messed up, I missed the meeting yesterday and will have to miss the wallet meeting today too if its on
2092019-03-29T18:32:36  <meshcollider> Do people have topics they want to discuss? It should start in half an hour if my calculation is right, anyone who wants to can chair it
2102019-03-29T18:38:19  *** qu4ku has quit IRC
2112019-03-29T18:50:02  *** jimmysong_ has quit IRC
2122019-03-29T19:02:01  <MarcoFalke> Doesn't seem like it :)
2132019-03-29T19:02:31  <achow101> I have a topic, but not at computer now. Give me a few minutes
2142019-03-29T19:03:41  *** andcoisqu has quit IRC
2152019-03-29T19:04:43  <jnewbery> hi! I had a small topic.
2162019-03-29T19:05:14  <jnewbery> shall I wait until achow101 is back?
2172019-03-29T19:05:30  <sipa> i'm here, but don't have anything
2182019-03-29T19:05:36  <sipa> let's wait
2192019-03-29T19:10:03  <achow101> here now
2202019-03-29T19:10:28  <jnewbery> sipa: care to chair?
2212019-03-29T19:10:38  <sipa> #startmeeting
2222019-03-29T19:10:38  <lightningbot> Meeting started Fri Mar 29 19:10:38 2019 UTC.  The chair is sipa. Information about MeetBot at http://wiki.debian.org/MeetBot.
2232019-03-29T19:10:38  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2242019-03-29T19:10:42  <sipa> yow, topics?
2252019-03-29T19:10:52  <jnewbery> suggested topic: rebroadcast behaviour
2262019-03-29T19:10:55  <instagibbs> hmm calendar is off by a week, here
2272019-03-29T19:11:29  <jnewbery> instagibbs: it was delayed by a week during FC and didn't revert
2282019-03-29T19:12:05  <achow101> suggested topic: non-hardened derivation paths
2292019-03-29T19:12:12  <sipa> #topic rebroadcast behaviour
2302019-03-29T19:12:51  <instagibbs> I see we finally have rebroadcast tests :)
2312019-03-29T19:13:01  <jnewbery> I've been looking at wallet rebroadcasts. The current behaviour is: set a timer for random (0, 30). When it pops rebroadcast all unconfirmed wallet txs. Set timer again.
2322019-03-29T19:13:15  *** DeanGuss has quit IRC
2332019-03-29T19:13:25  <sipa> but only if there has been a new block since the previous rebroadcast?
2342019-03-29T19:13:29  <jnewbery> (it's not quite as bad as that because each peer has a bloom filter so we won't actually rebroadcast until it's been purged from there)
2352019-03-29T19:13:35  <jnewbery> ah yes, as long as there's been a block
2362019-03-29T19:13:44  <jnewbery> I have a couple of suggested changes
2372019-03-29T19:14:03  <jnewbery> 1. separate the scheduling, so each tx is on its own timer, instead of sending them all at once
2382019-03-29T19:14:28  <jnewbery> 2. have the wallet remember some number of random txs it sees from the mempool, and add those to its rebroadcast list as decoys
2392019-03-29T19:14:43  <jnewbery> wanted to get some concept feedback on those before I started coding up
2402019-03-29T19:15:16  <sipa> so (1) is problematic if there are interdependent unconfirmed transactions in your wallet
2412019-03-29T19:15:31  <sipa> as you may end up sending a child to a different peer than the parent
2422019-03-29T19:15:35  <sipa> gmaxwell: opinions? ^
2432019-03-29T19:16:01  <jnewbery> in (1), I'd think we'd still send each tx to all peers
2442019-03-29T19:16:08  <sipa> oh!
2452019-03-29T19:16:18  <jnewbery> just not all at the same time
2462019-03-29T19:16:28  <instagibbs> trickle rather than flood
2472019-03-29T19:16:38  <sipa> right, but you may send the child before the parent
2482019-03-29T19:16:58  <sipa> (they get sorted in the broadcast buffer before actual sending, but that's just a few-seconds timer)
2492019-03-29T19:17:29  <sipa> i don't know whether the rebroadcast mechanism in the wallet currently actually cares about that
2502019-03-29T19:17:39  <jnewbery> I think it doesn't, but I'd have to recheck
2512019-03-29T19:17:55  <sipa> yeah, but if it sends all unconfirmed txn, they'll get sorted before broadcast
2522019-03-29T19:18:05  <jnewbery> oh, where does that happen?
2532019-03-29T19:18:30  <sipa> sendmessages
2542019-03-29T19:19:29  <sipa> there's a poisson distributed per-peer timer (but simultaneous for all inbound connections) that flushes a buffer of to-be-broadcast txn
2552019-03-29T19:20:00  <jnewbery> yeah, I see it now
2562019-03-29T19:20:05  <sipa> and it sorted first by dependency order and then lexicographically
2572019-03-29T19:20:09  <sipa> *sorts
2582019-03-29T19:20:37  <sipa> so if you announce an txid within a few seconds of each other, there's a high chance they'll end up being sorted correctly before actual broadcast
2592019-03-29T19:20:44  <jnewbery>  // Topologically and fee-rate sort the inventory we send for privacy and priority reasons.
2602019-03-29T19:20:51  <sipa> yeah, that
2612019-03-29T19:21:00  <sipa> oh yes, feerate; not lexicographically
2622019-03-29T19:21:10  <gmaxwell> (1) could consider only the deepest ancestors and announce all the parents at once.
2632019-03-29T19:21:19  <gmaxwell> ignoring the details (1) sounds like a very important improvement.
2642019-03-29T19:22:12  *** tryphe_ has quit IRC
2652019-03-29T19:22:29  <jnewbery> is the wallet aware of dependencies in its transactions?
2662019-03-29T19:22:33  <sipa> yes
2672019-03-29T19:22:37  *** tryphe_ has joined #bitcoin-core-dev
2682019-03-29T19:22:49  <gmaxwell> er only the deepest children.
2692019-03-29T19:24:02  *** captjakk has quit IRC
2702019-03-29T19:24:08  <gmaxwell> (2) I don't have a problem with but I think the benefit is a bit dubious, like random txn by itself very likely provides no privacy improvement, because only the real sender or recipent will send txn for all of a single address/linked address consistently.   It's sometimes hard to tell where the line is between snake oil that just adds complexity to the codebase for no protection against an
2712019-03-29T19:24:09  <gmaxwell> even slightly incompetent attacker, vs fuzzing things up in a way that provides incremental privacy even though far from perfect
2722019-03-29T19:24:18  <sipa> jnewbery: mapTxSpends
2732019-03-29T19:24:22  *** Sentineo has joined #bitcoin-core-dev
2742019-03-29T19:24:27  <gmaxwell> I would think though that matching random addresses would be a lot better than random txn.
2752019-03-29T19:25:16  <gmaxwell> I think a (3) avoiding pointles retransmissions would be more helpful.  But I would happily review an implementation of (2), reservations aside.
2762019-03-29T19:25:31  <jnewbery> Do we know what percentage of txs are re-used addresses? And what number of those re-used addresses have multiple unconfirmed txs at the same time?
2772019-03-29T19:25:59  <gmaxwell> jnewbery: 'most' (I expect sipa will provide some numbers) But it's not just a same time question:
2782019-03-29T19:26:04  <sipa> jnewbery: also, poisson distributed rebroadcast events are probably more private than uniform distributed ones
2792019-03-29T19:26:24  <gmaxwell> what I think it should do is per node pick a random value (e.g. the addr man randomizer) and use that to consistently select some small portion of addresses to rebroadcast.
2802019-03-29T19:26:42  <gmaxwell> so that over months of time we're consisently rebroadcasting the same other addresses.
2812019-03-29T19:26:47  *** captjakk has joined #bitcoin-core-dev
2822019-03-29T19:26:57  *** spaced0ut has quit IRC
2832019-03-29T19:27:12  <gmaxwell> Yeah uniform leaks information that possion doesn't, possion is the distribution you get from memoryless processes.
2842019-03-29T19:27:27  *** captjakk has joined #bitcoin-core-dev
2852019-03-29T19:27:53  <jnewbery> if you're talking about months of time, then presumably you'd need to save this to disk
2862019-03-29T19:28:08  <sipa> the addrman randomizer is stored on disk
2872019-03-29T19:28:20  <gmaxwell> Thats why I specified that one.
2882019-03-29T19:28:37  <jnewbery> So you're saying this behaviour should live in the node rather than the wallet?
2892019-03-29T19:28:47  <sipa> wallet is easier i think
2902019-03-29T19:29:01  <gmaxwell> also if you wipe out your peers.day because you're trying to avoid addrman based fingerprinting then you'll also wipe rebroadcast fingerprinting.
2912019-03-29T19:29:01  <jnewbery> the wallet isn't aware of peers
2922019-03-29T19:29:06  <gmaxwell> I think nodes without wallets should d this too.
2932019-03-29T19:29:07  <sipa> but it would possibly result in identifiable behavior that can be detected if a wallet file moves to another node
2942019-03-29T19:29:23  <gmaxwell> because there are many walletless nodes that would provide cover...
2952019-03-29T19:29:41  <gmaxwell> maybe thats not realistic for engineering reasons. ::shrugs:: I'm just talking spherical cows here.
2962019-03-29T19:30:16  <gmaxwell> In any case, if it isn't consistent like this, it's really obvious to me how attackers will filter it out. Monitor, and look for dispositive failures to rebroadcast. The real source won't have them, the fake sources will.
2972019-03-29T19:30:19  <jnewbery> I think the implementation can be quite minimal if the wallet just keeps its own list of txs and doesn't try to distinguish behaviour between peers
2982019-03-29T19:30:53  <gmaxwell> and given someone that already has network wide monitoring that filtering is probably only a dozen lines of code/query.
2992019-03-29T19:31:13  <jnewbery> are you saying genuine wallet rebroadcasts should also be to only one peer?
3002019-03-29T19:31:40  <jnewbery> because if its to all peers that's different behaviour than decoy rebroadcasts and would be easy to spot
3012019-03-29T19:32:07  <gmaxwell> no, both should be to all peers.
3022019-03-29T19:32:33  <jnewbery> then I've misunderstood your 'per node' comment above
3032019-03-29T19:33:05  <gmaxwell> jnewbery: my node being different from yours.
3042019-03-29T19:33:18  <jnewbery> ok
3052019-03-29T19:33:19  <gmaxwell> I prefer to rebroadcast 1apple you prefer to rebroadcast 1spatula.
3062019-03-29T19:33:25  <jnewbery> yep
3072019-03-29T19:33:34  <gmaxwell> and if I restart I still prefer 1apple.
3082019-03-29T19:33:54  <gmaxwell> so an attacker can't tell if I like 1apple's addresses because of my random number or because I am 1apple.
3092019-03-29T19:34:16  *** bitcoin-git has joined #bitcoin-core-dev
3102019-03-29T19:34:16  <bitcoin-git> [bitcoin] promag opened pull request #15700: rfc: Synchronize validation interface registration (master...2019-03-sync-validation-interface-registration) https://github.com/bitcoin/bitcoin/pull/15700
3112019-03-29T19:34:17  *** bitcoin-git has left #bitcoin-core-dev
3122019-03-29T19:34:34  <sipa> so what if the address you pick for rebroadcasts suddenly gets a ton of transactions
3132019-03-29T19:34:52  <gmaxwell> sipa: well you're going to relay them on the network regardless.
3142019-03-29T19:35:00  <gmaxwell> So I don't think thats actually a major cost?
3152019-03-29T19:35:41  <sipa> ah right, if it's per node they'd just be broadcast from the mempool directly; no need to copy/store them elsewhere
3162019-03-29T19:36:10  <sipa> though you do need to keep track of txn that spend outputs assigned to the addresses you've chosen
3172019-03-29T19:36:33  <sipa> but that could just be a boolean per-tx i guess
3182019-03-29T19:37:34  <gmaxwell> right. all these considerations is why I'm a little dubious. I think the simplest version does little to nothing. And I'm not sure of the bound of the complexity on an effort to really be indistinguishable. I mean mean one way would be to effectively importaddress on random addresses you see with a flag to hide them in the wallet but implemented that way would have too many DOS potentials.
3192019-03-29T19:38:06  <gmaxwell> it would, however, have a pretty strong guarentee that you'd treat them the same, making them very hard to distinguish.
3202019-03-29T19:38:18  <gmaxwell> though it would also only work if you have a wallet.
3212019-03-29T19:38:49  <jnewbery> I think just selecting random txs is surely better than little to nothing
3222019-03-29T19:39:04  <sipa> another approach is having the rebroadcast mechanism be purely in the node, and have it mark some subset of transactions... but then have the wallet forcibly set that mark on its own transactions too
3232019-03-29T19:39:15  *** owowo has quit IRC
3242019-03-29T19:39:20  <sipa> but the wallet doesn't do the rebroadcasting
3252019-03-29T19:40:22  <gmaxwell> jnewbery: I think any existing deanon attackers can filter out random tx rebroadcasts fairly reliably with a line of code, maybe its still worth doing. We have other paper thin privacy mechenisms (e.g. most of the node anti-fingerprinting).
3262019-03-29T19:41:08  <jnewbery> but if they're random, some of them will be for addresses that aren't re-used. How would the attacked filter those out?
3272019-03-29T19:41:27  *** owowo has joined #bitcoin-core-dev
3282019-03-29T19:42:52  <gmaxwell> jnewbery: A couple ways: for rebroadcast purposes every coin that isn't lost is reused, since senders and recipents both rebroadcast. Also even when addresses aren't reused, they're co-used in inputs with other transactions. So broadcasting of the complete address cluster is also a fairly strong hurestic.
3292019-03-29T19:43:28  <gmaxwell> I think you've convinced me that in at least some cases it would be indistinguishable.
3302019-03-29T19:43:46  <jnewbery> Many txs don't get rebroadcast at all and are confirmed in the next block
3312019-03-29T19:43:53  <gmaxwell> e.g. one side of send/recieve doesn't need any rebroadcast, no reuse, no useful information from clustering.
3322019-03-29T19:44:28  <jnewbery> Right. An attacker can't tell if you would have rebroadcast
3332019-03-29T19:44:59  <gmaxwell> (thats also, aside, a reason rebroadcasts should be possion timed)
3342019-03-29T19:45:03  <sipa> maybe we should move to achow101's topic?
3352019-03-29T19:45:15  *** saks has quit IRC
3362019-03-29T19:45:32  <jnewbery> I don't think I need anything else on this for now. Thanks for the input!
3372019-03-29T19:45:56  <achow101> I've started working native descriptor wallets and I just wanted some opinions on some parts of the design.
3382019-03-29T19:46:05  <sipa> cool
3392019-03-29T19:46:27  <sipa> #topic non-hardened derivation paths
3402019-03-29T19:46:51  <achow101> right now I have the wallet make 6 descriptors, in pairs of 3. each pair has an internal and external descriptor, and each pair for each of the address types
3412019-03-29T19:47:14  <sipa> makes sense
3422019-03-29T19:47:20  <achow101> it uses derivation paths that we currently use in the wallet, but I think it would be better if we used bip 44/49/89
3432019-03-29T19:47:51  <achow101> thoughts? it would mean that we use non-hardened derivation paths
3442019-03-29T19:47:53  <sipa> i think using non-hardened derivation paths is fine if there is no way to export the individual private keys
3452019-03-29T19:48:29  <gmaxwell> I think it's necessary to disable key export on anything non-hardened.
3462019-03-29T19:48:35  <achow101> as it is now, we need to have a new seed for each address type or we'll end up using keys accidentally
3472019-03-29T19:48:56  <achow101> I think that the only export that will be possible is exporting the entire private descriptor itself
3482019-03-29T19:48:57  <sipa> achow101: you would certainly use distinct paths for each of the address types
3492019-03-29T19:49:03  <sipa> achow101: agree
3502019-03-29T19:49:10  <gmaxwell> Also, I don't think we should be defaulting to using non-hardened unless we're actually making real use of its abilityies (like to cogenerate addresses with an external signer).
3512019-03-29T19:49:13  <achow101> i'll be disabling dumpprivkey and all of the imports for descriptor wallets
3522019-03-29T19:50:08  <sipa> gmaxwell: it also has the advantage of not needing to decrypt the wallet to generate more addresses
3532019-03-29T19:50:26  <gmaxwell> so generate 100,000 addresses the first go. :)
3542019-03-29T19:50:44  <gmaxwell> it's a lot of fragility to save a megabyte of file size. :P
3552019-03-29T19:50:46  <achow101> gmaxwell: it has the advantage of making the wallet file extremely small
3562019-03-29T19:51:16  <gmaxwell> the wallet file grows from transactions regardless. if you're actually using addresses it'll get big.
3572019-03-29T19:51:50  <sipa> anyway, i think it certainly makes sense to support nonhardened derivation
3582019-03-29T19:51:58  <gmaxwell> Sure.
3592019-03-29T19:52:05  <achow101> right now the thing I don't like is that it needs 3 different seeds, one for each address type
3602019-03-29T19:52:28  <sipa> achow101: that shouldn't be needed; you can use distinct derivation paths even when using hardened?
3612019-03-29T19:52:46  <gmaxwell> as far as making wallets small, that I think is mostly interesting for backups, and for that it might be best to have tools/rpcs that strips wallets for backup purposes.
3622019-03-29T19:52:52  <achow101> sipa: yes, but I don't really like having to introduce yet another set of derivation paths that people have to consider
3632019-03-29T19:53:00  <achow101> vs. using existing standards
3642019-03-29T19:53:15  *** timothy has quit IRC
3652019-03-29T19:53:22  <sipa> achow101: that's why you encode it as a descriptor; it's universal :)
3662019-03-29T19:53:41  <sipa> but sure- i agree at a high level it's unnecessary to introduce new standards when existing ones exist
3672019-03-29T19:54:01  <sipa> the question is whether hardened or unhardened is more desirable - i don't know, and it may depend on the situation
3682019-03-29T19:54:07  <gmaxwell> This is just broken.
3692019-03-29T19:54:23  <achow101> ?
3702019-03-29T19:54:47  <gmaxwell> 'existing standards' were made by people considering entirely different use cases and deployment enviroments (hardware wallets)
3712019-03-29T19:55:17  <gmaxwell> and with a different focus on security (a lot closer to 'who cares')
3722019-03-29T19:55:32  <sipa> well when we'd use a nonhardened derivation (for external reasons) it makes sense to follow those standards
3732019-03-29T19:55:46  <sipa> the question remains whether or not to use hardened or not
3742019-03-29T19:55:58  *** DeanGuss has joined #bitcoin-core-dev
3752019-03-29T19:56:00  <gmaxwell> sipa: it might, if it is otherwise fine and would actually result in some kind of useful compatibility.
3762019-03-29T19:56:33  <gmaxwell> like we'll never be compatible with electrum (say) by using the same path, simply because we generate parllel native and compatibility addresses.
3772019-03-29T19:56:54  <achow101> gmaxwell: the plan for descriptor wallets is not generate them in parallel
3782019-03-29T19:57:15  <achow101> each address type will have it's own derivation path base
3792019-03-29T19:57:48  <sipa> yeah, so your bitcoin core wallet will correspond to a union of several things that are (possibly) compatible with an electrum wallet individually
3802019-03-29T19:58:55  <gmaxwell> a wallet where you can recover part of the funds and the rest are just invisibly lost isn't compatible though, if anything its a liability.
3812019-03-29T19:59:13  <sipa> right
3822019-03-29T20:00:42  <achow101> anywys, it seems like the preference is to use hardened
3832019-03-29T20:01:11  <gmaxwell> Generally thats my strong preference, except in cases where there is a 'application layer' gain from otherwise.
3842019-03-29T20:01:43  <gmaxwell> Not just some 'its easier to write this way' or 'wallet file is somewhat smaller for unspecified benenfits'
3852019-03-29T20:02:43  <sipa> seems we're out of time
3862019-03-29T20:03:05  <gmaxwell> I really regret ever coming up with public derrivation and wish I could take it back,  The original application I had for it is still unavailable to people (so your web server could securely generate fresh addresses for you) in practice... and it gets applied *everywhere* simply because reusing a key is simpler to implement.
3872019-03-29T20:03:26  <achow101> well that's all I had for today. there was something else I wanted to discuss, but I don't remember what that was
3882019-03-29T20:03:40  <achow101> so clearly it wasn't very important
3892019-03-29T20:04:19  <gmaxwell> .. and its resulted in funds loss, and it also results in expectations we won't be able to support for post ECC keys.
3902019-03-29T20:04:46  <sipa> #endmeeting
3912019-03-29T20:04:46  <lightningbot> Meeting ended Fri Mar 29 20:04:46 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
3922019-03-29T20:04:46  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-03-29-19.10.html
3932019-03-29T20:04:46  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-03-29-19.10.txt
3942019-03-29T20:04:46  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-03-29-19.10.log.html
3952019-03-29T20:05:57  <achow101> gmaxwell: well it's been useful for hardwre wallets. asking a hardware wallet for a few thousand keys is not exactly a fun time
3962019-03-29T20:06:14  *** Krellan has joined #bitcoin-core-dev
3972019-03-29T20:07:05  <gmaxwell> achow101: yes, though really that isn't at all fundimental.
3982019-03-29T20:07:31  <gmaxwell> like if it didn't exist, hardware wallets would just cost $5 have a 10x faster cpu, and a faster interface, and no one would notice otherwise.
3992019-03-29T20:07:44  <gmaxwell> (or alternatively they'd just support a single address... :P)
4002019-03-29T20:07:51  <gmaxwell> er cost $5 more
4012019-03-29T20:08:48  <gmaxwell> I also agree that they're not terribly bad for the hardware wallet case.  That isn't really all that different from the orignal 'webserver' usecase, except your wallet is the webserver.
4022019-03-29T20:09:31  <gwillen> this is more generally the "not having to expose your private key in more places than necessary" usecase, which seems laudable
4032019-03-29T20:10:04  <gmaxwell> though also the security of generating addresse on an untrusted device is kinda dubious. eventually the bad guys will have taken all the low hanging fruit and the next set of attacks will just be to make createnewaddress like interfaces return attacker addresses. :P
4042019-03-29T20:10:08  <gwillen> although due to not trusting software, these days I always check new addresses against each other on both machines anyway
4052019-03-29T20:10:11  <gwillen> yeah
4062019-03-29T20:10:37  <gwillen> you could very well generate new addresses independently in parallel on multiple devices and check them that way
4072019-03-29T20:10:41  <gwillen> with none of them being the private device
4082019-03-29T20:10:45  <gwillen> but ain't nobody got time for that
4092019-03-29T20:11:20  <gmaxwell> gwillen: there are goals in conflict, "reuse private keys" = bad. "use keys too much" =bad.  Essentially all non-hardened keys share the same private key, so it's reuse of a private key.
4102019-03-29T20:11:41  <gmaxwell> gwillen: indeed.
4112019-03-29T20:13:44  <gwillen> reuse of private keys being bad seems very implementation- and UX-specific somehow
4122019-03-29T20:14:13  <gwillen> like, if you treat it as "a series of addresses generated by a single master key, there are no separate individual keys and the software will never give you such a thing" then you mitigate the user-confusion issue
4132019-03-29T20:20:36  *** jonatack has joined #bitcoin-core-dev
4142019-03-29T20:22:12  *** tryphe_ has quit IRC
4152019-03-29T20:22:39  *** tryphe_ has joined #bitcoin-core-dev
4162019-03-29T20:22:59  *** dviola has joined #bitcoin-core-dev
4172019-03-29T20:38:00  *** StopAndDecrypt has joined #bitcoin-core-dev
4182019-03-29T20:38:09  *** StopAndDecrypt has quit IRC
4192019-03-29T20:38:10  *** StopAndDecrypt has joined #bitcoin-core-dev
4202019-03-29T20:38:54  *** StopAndDecrypt_ has quit IRC
4212019-03-29T20:39:51  *** obsrver has quit IRC
4222019-03-29T20:49:55  *** dviola has quit IRC
4232019-03-29T20:54:08  *** harrymm has joined #bitcoin-core-dev
4242019-03-29T21:17:24  *** belcher has quit IRC
4252019-03-29T21:18:46  *** e4xit has quit IRC
4262019-03-29T21:22:11  *** tryphe_ has quit IRC
4272019-03-29T21:22:39  *** tryphe_ has joined #bitcoin-core-dev
4282019-03-29T21:23:13  *** e4xit has joined #bitcoin-core-dev
4292019-03-29T21:38:02  *** Zenton has joined #bitcoin-core-dev
4302019-03-29T21:43:22  *** bitcoin-git has joined #bitcoin-core-dev
4312019-03-29T21:43:22  <bitcoin-git> [bitcoin] jnewbery closed pull request #15010: [wallet] Fix getbalance with minconf (master...fix_getbalance_with_minconf) https://github.com/bitcoin/bitcoin/pull/15010
4322019-03-29T21:43:33  *** bitcoin-git has left #bitcoin-core-dev
4332019-03-29T21:43:38  *** mn94958851 has joined #bitcoin-core-dev
4342019-03-29T21:43:38  *** mn94958856 has joined #bitcoin-core-dev
4352019-03-29T21:43:38  *** mn9495882 has joined #bitcoin-core-dev
4362019-03-29T21:47:08  *** mn9495881 has quit IRC
4372019-03-29T21:47:22  *** mn94958855 has quit IRC
4382019-03-29T21:47:22  *** mn949588 has quit IRC
4392019-03-29T21:54:45  *** DeanGuss has quit IRC
4402019-03-29T22:04:32  *** zivl has joined #bitcoin-core-dev
4412019-03-29T22:06:07  *** Guyver2 has quit IRC
4422019-03-29T22:17:20  *** justanotheruser has joined #bitcoin-core-dev
4432019-03-29T22:20:04  <achow101> sipa: how come ExpandFromCache returns ExpandHelper(..) == 0 ? Seems like a bug to me
4442019-03-29T22:21:17  <achow101> oh, nvm. I misread part of it
4452019-03-29T22:22:13  *** tryphe_ has quit IRC
4462019-03-29T22:22:39  *** tryphe_ has joined #bitcoin-core-dev
4472019-03-29T22:25:59  *** bitcoin-git has joined #bitcoin-core-dev
4482019-03-29T22:25:59  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/0baf4b1f9663...00ca24b68fc4
4492019-03-29T22:26:00  <bitcoin-git> bitcoin/master 1111f07 MarcoFalke: test: .style.yapf: Set column_limit=160
4502019-03-29T22:26:00  <bitcoin-git> bitcoin/master 00ca24b MarcoFalke: Merge #15533: test: .style.yapf: Set column_limit=160
4512019-03-29T22:26:11  *** bitcoin-git has left #bitcoin-core-dev
4522019-03-29T22:26:45  *** bitcoin-git has joined #bitcoin-core-dev
4532019-03-29T22:26:45  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #15533: test: .style.yapf: Set column_limit=160 (master...1903-testNoPep8Collim) https://github.com/bitcoin/bitcoin/pull/15533
4542019-03-29T22:26:46  *** bitcoin-git has left #bitcoin-core-dev
4552019-03-29T22:28:03  *** bitcoin-git has joined #bitcoin-core-dev
4562019-03-29T22:28:03  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/00ca24b68fc4...79c345a0114c
4572019-03-29T22:28:04  <bitcoin-git> bitcoin/master afc06fc Torkel Rogstad: rpc: Fix help text for signtransactionwithXXX
4582019-03-29T22:28:04  <bitcoin-git> bitcoin/master 79c345a MarcoFalke: Merge #15669: rpc: Fix help text for signtransactionwithXXX
4592019-03-29T22:28:06  *** bitcoin-git has left #bitcoin-core-dev
4602019-03-29T22:28:53  *** bitcoin-git has joined #bitcoin-core-dev
4612019-03-29T22:28:53  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #15669: rpc: Fix help text for signtransactionwithXXX (master...signrawtx-rpc-help) https://github.com/bitcoin/bitcoin/pull/15669
4622019-03-29T22:28:54  *** bitcoin-git has left #bitcoin-core-dev
4632019-03-29T22:29:24  *** jnewbery has quit IRC
4642019-03-29T22:36:03  *** dqx__ has joined #bitcoin-core-dev
4652019-03-29T22:38:56  *** dqx_ has quit IRC
4662019-03-29T22:43:58  *** spinza has quit IRC
4672019-03-29T22:49:58  *** spinza has joined #bitcoin-core-dev
4682019-03-29T22:58:00  *** passedpawn has joined #bitcoin-core-dev
4692019-03-29T23:02:15  *** passedpawn has quit IRC
4702019-03-29T23:03:54  *** ctrlbreak_MAD has joined #bitcoin-core-dev
4712019-03-29T23:07:30  *** ctrlbreak has quit IRC
4722019-03-29T23:22:04  *** tryphe_ has quit IRC
4732019-03-29T23:22:32  *** tryphe_ has joined #bitcoin-core-dev
4742019-03-29T23:23:57  *** captjakk has quit IRC
4752019-03-29T23:24:13  *** schmidty has quit IRC
4762019-03-29T23:28:31  *** tryphe_000 has joined #bitcoin-core-dev
4772019-03-29T23:31:46  *** tryphe_ has quit IRC
4782019-03-29T23:41:36  *** tryphe has joined #bitcoin-core-dev
4792019-03-29T23:42:07  *** tryphe_000 has quit IRC
4802019-03-29T23:46:43  *** tryphe has quit IRC
4812019-03-29T23:48:19  *** tryphe has joined #bitcoin-core-dev