12017-12-11T00:01:37 *** galapagos has quit IRC
22017-12-11T00:13:35 *** DvdKhl has quit IRC
32017-12-11T00:17:30 *** drtheemu has quit IRC
42017-12-11T00:17:47 *** drtheemu has joined #bitcoin-core-dev
52017-12-11T00:20:07 *** promag has joined #bitcoin-core-dev
62017-12-11T00:28:52 *** imabinarydigit01 has quit IRC
72017-12-11T00:29:09 *** imabinarydigit01 has joined #bitcoin-core-dev
82017-12-11T00:33:34 *** imabinarydigit01 has quit IRC
92017-12-11T00:33:57 *** intcat has quit IRC
102017-12-11T00:34:43 *** Cogito_Ergo_Sum has quit IRC
112017-12-11T00:35:15 *** intcat has joined #bitcoin-core-dev
122017-12-11T00:35:17 *** imabinarydigit01 has joined #bitcoin-core-dev
132017-12-11T00:35:39 *** cluelessperson has quit IRC
142017-12-11T00:36:30 *** cluelessperson has joined #bitcoin-core-dev
152017-12-11T00:38:18 *** imabinarydigit01 has quit IRC
162017-12-11T00:38:55 *** imabinarydigit01 has joined #bitcoin-core-dev
172017-12-11T00:38:57 *** Kozuch has quit IRC
182017-12-11T00:39:45 *** tknp has joined #bitcoin-core-dev
192017-12-11T00:41:40 *** silviud has joined #bitcoin-core-dev
202017-12-11T00:47:51 <phantomcircuit> running master with txindex=1 i just had an oom crash blocksonly mode dbcache=128
212017-12-11T00:48:52 *** Babozor has joined #bitcoin-core-dev
222017-12-11T00:52:00 *** cluelessperson has quit IRC
232017-12-11T00:52:12 *** intcat has quit IRC
242017-12-11T00:52:47 *** promag has quit IRC
252017-12-11T00:52:51 *** cluelessperson has joined #bitcoin-core-dev
262017-12-11T00:53:10 *** cluelessperson has quit IRC
272017-12-11T00:54:00 <phantomcircuit> im now up to 5GB of resident memory
282017-12-11T00:54:19 <phantomcircuit> something is wrong here i believe
292017-12-11T00:55:51 *** intcat has joined #bitcoin-core-dev
302017-12-11T01:03:34 *** Ylbam has quit IRC
312017-12-11T01:03:47 *** cluelessperson has joined #bitcoin-core-dev
322017-12-11T01:04:58 <phantomcircuit> yeah there's a memory leak with this configuration
332017-12-11T01:13:02 *** saint_ has joined #bitcoin-core-dev
342017-12-11T01:13:17 *** Mattie-161 has quit IRC
352017-12-11T01:13:30 *** Mattie-161 has joined #bitcoin-core-dev
362017-12-11T01:16:06 *** bule has joined #bitcoin-core-dev
372017-12-11T01:21:07 *** intcat has quit IRC
382017-12-11T01:22:09 *** drtheemu has quit IRC
392017-12-11T01:22:49 *** intcat has joined #bitcoin-core-dev
402017-12-11T01:43:12 *** silviud has quit IRC
412017-12-11T02:12:39 *** intcat has quit IRC
422017-12-11T02:13:33 *** intcat has joined #bitcoin-core-dev
432017-12-11T02:18:38 *** intcat has quit IRC
442017-12-11T02:19:02 *** assaad has joined #bitcoin-core-dev
452017-12-11T02:19:49 *** intcat has joined #bitcoin-core-dev
462017-12-11T02:28:11 *** Randolf has quit IRC
472017-12-11T02:35:05 *** galapagos has joined #bitcoin-core-dev
482017-12-11T03:02:30 *** goatig has quit IRC
492017-12-11T03:08:33 <BlueMatt> phantomcircuit: on master?
502017-12-11T03:08:44 <BlueMatt> phantomcircuit: you want #11824
512017-12-11T03:08:45 <gribble> https://github.com/bitcoin/bitcoin/issues/11824 | Block ActivateBestChain to empty validationinterface queue by TheBlueMatt · Pull Request #11824 · bitcoin/bitcoin · GitHub
522017-12-11T03:08:49 <BlueMatt> should fix it right up for you
532017-12-11T03:09:24 <BlueMatt> (plz review)
542017-12-11T03:12:38 *** intcat has quit IRC
552017-12-11T03:13:29 *** intcat has joined #bitcoin-core-dev
562017-12-11T03:13:45 *** imabinarydigit01 has quit IRC
572017-12-11T03:14:02 *** imabinarydigit01 has joined #bitcoin-core-dev
582017-12-11T03:21:13 *** justan0theruser has joined #bitcoin-core-dev
592017-12-11T03:21:39 *** justanotheruser has quit IRC
602017-12-11T03:23:35 *** intcat has quit IRC
612017-12-11T03:24:31 *** intcat has joined #bitcoin-core-dev
622017-12-11T03:25:50 *** Chris_Stewart_5 has joined #bitcoin-core-dev
632017-12-11T03:27:20 *** zombieC has quit IRC
642017-12-11T03:31:02 *** Randolf has joined #bitcoin-core-dev
652017-12-11T03:40:25 *** travischron123 has joined #bitcoin-core-dev
662017-12-11T03:59:37 *** harrymm has quit IRC
672017-12-11T04:03:12 *** Chris_Stewart_5 has quit IRC
682017-12-11T04:06:47 *** intcat has quit IRC
692017-12-11T04:08:45 *** intcat has joined #bitcoin-core-dev
702017-12-11T04:09:30 <phantomcircuit> BlueMatt, so what there's just some queue that's being consumed much much slower than produced?
712017-12-11T04:09:41 <BlueMatt> phantomcircuit: yes, cause cs_main
722017-12-11T04:13:45 <phantomcircuit> BlueMatt, wait it's a queue of shared pointers?
732017-12-11T04:13:53 <BlueMatt> phantomcircuit: yes?
742017-12-11T04:14:05 <phantomcircuit> oh to the full CBlock yeah ok so it's the full block staying in memory nvm
752017-12-11T04:14:10 <BlueMatt> yupyup
762017-12-11T04:22:12 * luke-jr peers at our transaction list CSV export not adding up to the right balance
772017-12-11T04:24:48 <sipa> poll: when applying validateaddress to a (known) native witness multisig address, should it (A) not show the keys in it (B) show the keys in it as pubkeys (C) show the keys in it as legacy addresses (like P2SH multisig now) or (D) show the keys in it as native segwit addresses
782017-12-11T04:26:16 <luke-jr> I think B? C and D are ugly.
792017-12-11T04:26:38 <sipa> luke-jr: i agree
802017-12-11T04:26:55 *** tripleslash has quit IRC
812017-12-11T04:27:26 <sipa> though in the case of B, should be also do that for non-segwit?
822017-12-11T04:27:40 <luke-jr> probably; can it do so compatibly?
832017-12-11T04:28:04 <sipa> yeah, would need to be in a separate key
842017-12-11T04:28:12 <sipa> "pubkeys" instead of "addresses"
852017-12-11T04:28:26 <luke-jr> ah
862017-12-11T04:31:41 *** justanotheruser has joined #bitcoin-core-dev
872017-12-11T04:34:46 *** justan0theruser has quit IRC
882017-12-11T04:36:30 *** justanotheruser has quit IRC
892017-12-11T04:36:50 *** justanotheruser has joined #bitcoin-core-dev
902017-12-11T04:58:32 <phantomcircuit> BlueMatt, is promise being used elsewhere?
912017-12-11T04:59:15 *** bule has quit IRC
922017-12-11T04:59:45 *** bule has joined #bitcoin-core-dev
932017-12-11T05:05:25 *** bule has quit IRC
942017-12-11T05:13:52 *** tknp has quit IRC
952017-12-11T05:19:36 *** intcat has quit IRC
962017-12-11T05:20:23 *** intcat has joined #bitcoin-core-dev
972017-12-11T05:34:37 *** intcat has quit IRC
982017-12-11T05:35:30 *** intcat has joined #bitcoin-core-dev
992017-12-11T05:40:56 *** go1111111 has quit IRC
1002017-12-11T05:50:22 *** travischron123 has quit IRC
1012017-12-11T05:50:35 *** Roberto_2000 has quit IRC
1022017-12-11T06:06:56 *** tknp has joined #bitcoin-core-dev
1032017-12-11T06:07:24 *** indistylo has joined #bitcoin-core-dev
1042017-12-11T06:10:30 *** zshlyk has joined #bitcoin-core-dev
1052017-12-11T06:13:27 *** indistylo has quit IRC
1062017-12-11T06:13:32 *** intcat has quit IRC
1072017-12-11T06:14:49 *** indistylo has joined #bitcoin-core-dev
1082017-12-11T06:21:40 *** Sillent has joined #bitcoin-core-dev
1092017-12-11T06:31:56 *** zshlyk has quit IRC
1102017-12-11T06:32:39 *** zshlyk has joined #bitcoin-core-dev
1112017-12-11T06:43:09 *** tknp has quit IRC
1122017-12-11T06:51:27 *** ekrok has quit IRC
1132017-12-11T07:01:42 *** blackbaba has joined #bitcoin-core-dev
1142017-12-11T07:06:20 *** ekrok has joined #bitcoin-core-dev
1152017-12-11T07:16:41 *** promag has joined #bitcoin-core-dev
1162017-12-11T07:19:17 *** promag has quit IRC
1172017-12-11T07:19:40 <mryandao> hmm, i'm trying to compile an older version of core (v0.7.0rc3), checked out the branch and did a clean, but there's no build instructions :(
1182017-12-11T07:22:24 <sipa> https://github.com/bitcoin/bitcoin/blob/v0.7.0rc3/doc/build-unix.txt
1192017-12-11T07:23:08 <mryandao> sipa: thanks :)
1202017-12-11T07:26:37 *** zshlyk has quit IRC
1212017-12-11T07:30:12 *** zshlyk has joined #bitcoin-core-dev
1222017-12-11T07:34:34 *** promag has joined #bitcoin-core-dev
1232017-12-11T07:39:51 *** promag has quit IRC
1242017-12-11T07:56:35 *** promag has joined #bitcoin-core-dev
1252017-12-11T07:57:47 *** promag has quit IRC
1262017-12-11T08:02:43 <warren> Does anyone use gitian with qemu-kvm instead of lxc?
1272017-12-11T08:03:04 <warren> MarcoFalke: have you tested your gitian instructions on Fedora 27? both with qemu-kvm and lxc?
1282017-12-11T08:03:40 <warren> Does anyone using gitian with qemu-kvm particularly on Ubuntu or Debian?
1292017-12-11T08:04:30 <Randolf> warren: You might also ask in the #qemu channel, just in case someone there can be helpful too. :)
1302017-12-11T08:04:46 <warren> Randolf: no, this is very gitian and bitcoin specific
1312017-12-11T08:04:51 <Randolf> Oh, okay.
1322017-12-11T08:04:59 *** promag has joined #bitcoin-core-dev
1332017-12-11T08:05:17 <Randolf> I was merely thinking of a potentially wider audience. :)
1342017-12-11T08:05:18 <warren> The Bitcoin gitian instructions say to use only lxc but the way I've used it for the past few years is with qemu-kvm instead
1352017-12-11T08:05:30 <Randolf> Cool!
1362017-12-11T08:05:39 <Randolf> Having more than one way to do things is always a plus.
1372017-12-11T08:05:40 <warren> Randolf: the way we qemu or lxc is very different from what most other people are familiar with
1382017-12-11T08:06:56 <Randolf> I'm familiar with qemu, and have implemented it for various clients (primarily to run MS-Windows on NetBSD hosts), but lxc is something I should probably look into then.
1392017-12-11T08:07:05 <Randolf> ...and also qemu-kvm.
1402017-12-11T08:08:10 <warren> qemu-kvm is just hardware accelerated qemu
1412017-12-11T08:08:28 <warren> using kvm as a hypervisor, I think is the terminology
1422017-12-11T08:10:27 <warren> http://wtogami.blogspot.com/2013/05/gitian-for-fedora.html I had been updating tools to make gitian work on Fedora since 2013 ... I used it with qemu-kvm since then.
1432017-12-11T08:10:53 *** yoctopede has joined #bitcoin-core-dev
1442017-12-11T08:11:23 <warren> But base-trusty-amd64.qcow2 generated on Fedora 25+ seems to be broken in some way that gets stuck with 100% CPU during qemu startup. If I copy a base-trusty-amd64.qcow2 image generated from Ubuntu onto my Fedora machine then gitian works.
1452017-12-11T08:11:52 <warren> So curious if MarcoFalke tested the qemu method of gitian
1462017-12-11T08:12:16 <warren> My packaged python-vm-builder is different than the "pip" method he uses to install it from Ubuntu
1472017-12-11T08:12:36 <Randolf> Does qcow (as opposed to qcow2) also exhibit the same problematic behaviour?
1482017-12-11T08:12:54 *** blackbaba has quit IRC
1492017-12-11T08:13:10 *** timothy has joined #bitcoin-core-dev
1502017-12-11T08:13:23 <warren> I don't think that's the issue. It's something installed or configured in the image file when it is generated.
1512017-12-11T08:13:32 *** zshlyk has quit IRC
1522017-12-11T08:14:56 <Randolf> Oh.
1532017-12-11T08:15:22 <warren> gitian qemu-kvm works just fine if I copy that base image from an Ubuntu machine
1542017-12-11T08:15:28 <Randolf> (Thanks for the link, by the way. I've opened it and will read it soon.)
1552017-12-11T08:15:49 <warren> something is wrong with that tool on Fedora, it worked in Fedora 24 last i know
1562017-12-11T08:18:37 <warren> I suspect it's grub2 or something not installing in the image file
1572017-12-11T08:20:26 <TD-Linux> have you tried both efi and bios boot with qemu?
1582017-12-11T08:20:37 *** promag has joined #bitcoin-core-dev
1592017-12-11T08:21:39 *** promag has quit IRC
1602017-12-11T08:29:37 <warren> it's something in the image file ...
1612017-12-11T08:29:44 <warren> image copied from Ubuntu works fine
1622017-12-11T08:30:03 *** yoctopede has quit IRC
1632017-12-11T08:30:39 *** yoctopede has joined #bitcoin-core-dev
1642017-12-11T08:34:28 *** CubicEarth has joined #bitcoin-core-dev
1652017-12-11T08:38:07 *** laurentmt has joined #bitcoin-core-dev
1662017-12-11T08:48:23 *** JackH has joined #bitcoin-core-dev
1672017-12-11T09:01:40 *** go1111111 has joined #bitcoin-core-dev
1682017-12-11T09:06:08 *** shesek has quit IRC
1692017-12-11T09:09:47 *** yoctopede has quit IRC
1702017-12-11T09:10:38 *** yoctopede has joined #bitcoin-core-dev
1712017-12-11T09:11:03 *** tattoovicious has joined #bitcoin-core-dev
1722017-12-11T09:12:52 *** yoctopede has quit IRC
1732017-12-11T09:13:46 *** yoctopede has joined #bitcoin-core-dev
1742017-12-11T09:17:47 *** Victor_sueca has joined #bitcoin-core-dev
1752017-12-11T09:19:15 *** shesek has joined #bitcoin-core-dev
1762017-12-11T09:19:41 *** Victorsueca has quit IRC
1772017-12-11T09:39:55 *** promag has joined #bitcoin-core-dev
1782017-12-11T09:49:44 *** CubicEarth has quit IRC
1792017-12-11T09:51:29 *** promag has quit IRC
1802017-12-11T10:01:51 *** pkx2 has joined #bitcoin-core-dev
1812017-12-11T10:02:24 *** pkx2 has quit IRC
1822017-12-11T10:05:02 *** CubicEarth has joined #bitcoin-core-dev
1832017-12-11T10:12:17 *** shesek has quit IRC
1842017-12-11T10:13:04 *** shesek has joined #bitcoin-core-dev
1852017-12-11T10:14:53 *** tattoovicious has quit IRC
1862017-12-11T10:17:55 *** Victor_sueca has quit IRC
1872017-12-11T10:18:16 *** Victorsueca has joined #bitcoin-core-dev
1882017-12-11T10:21:49 *** Victorsueca has quit IRC
1892017-12-11T10:23:39 *** yoctopede has quit IRC
1902017-12-11T10:24:35 *** yoctopede has joined #bitcoin-core-dev
1912017-12-11T10:24:50 *** yoctopede has quit IRC
1922017-12-11T10:24:59 *** promag has joined #bitcoin-core-dev
1932017-12-11T10:25:35 *** yoctopede has joined #bitcoin-core-dev
1942017-12-11T10:27:03 *** Victorsueca has joined #bitcoin-core-dev
1952017-12-11T10:33:21 *** promag has quit IRC
1962017-12-11T10:42:37 *** CubicEarth has quit IRC
1972017-12-11T10:42:57 *** CubicEarth has joined #bitcoin-core-dev
1982017-12-11T10:55:46 *** Kozuch has joined #bitcoin-core-dev
1992017-12-11T11:00:50 *** promag has joined #bitcoin-core-dev
2002017-12-11T11:23:24 *** yoctopede has quit IRC
2012017-12-11T11:25:50 *** yoctopede has joined #bitcoin-core-dev
2022017-12-11T11:30:04 *** cluelessperson has quit IRC
2032017-12-11T11:30:52 *** yoctopede has quit IRC
2042017-12-11T11:31:08 *** cluelessperson has joined #bitcoin-core-dev
2052017-12-11T11:31:37 *** yoctopede has joined #bitcoin-core-dev
2062017-12-11T11:32:06 *** cluelessperson has quit IRC
2072017-12-11T11:33:16 *** cluelessperson has joined #bitcoin-core-dev
2082017-12-11T11:43:46 *** cluelessperson has quit IRC
2092017-12-11T11:44:42 *** cluelessperson has joined #bitcoin-core-dev
2102017-12-11T12:00:52 *** FakeSatoshiLite has joined #bitcoin-core-dev
2112017-12-11T12:06:23 *** Guyver2 has joined #bitcoin-core-dev
2122017-12-11T12:10:15 *** zombieC has joined #bitcoin-core-dev
2132017-12-11T12:11:03 *** promag has quit IRC
2142017-12-11T12:12:13 *** promag has joined #bitcoin-core-dev
2152017-12-11T12:12:59 *** FakeSatoshiLite has quit IRC
2162017-12-11T12:15:15 *** ghost43 has quit IRC
2172017-12-11T12:25:30 *** ghost43 has joined #bitcoin-core-dev
2182017-12-11T12:26:47 *** yoctopede has quit IRC
2192017-12-11T12:27:05 *** cluelessperson has quit IRC
2202017-12-11T12:28:10 *** yoctopede has joined #bitcoin-core-dev
2212017-12-11T12:29:24 *** cluelessperson has joined #bitcoin-core-dev
2222017-12-11T12:34:02 *** cheese_ has joined #bitcoin-core-dev
2232017-12-11T12:38:19 *** cluelessperson has quit IRC
2242017-12-11T12:39:40 *** Danilo_ has joined #bitcoin-core-dev
2252017-12-11T12:39:40 *** Danilo_ is now known as danguafer
2262017-12-11T12:41:49 *** yoctopede has quit IRC
2272017-12-11T12:42:38 *** yoctopede has joined #bitcoin-core-dev
2282017-12-11T12:43:51 *** cluelessperson has joined #bitcoin-core-dev
2292017-12-11T12:46:01 *** cyber55 has quit IRC
2302017-12-11T12:56:52 <Provoostenator> mryandao: there may be some useful hints here too: https://gist.github.com/Sjors/70f14baf1f834f3547bf35553faff610
2312017-12-11T12:58:13 *** AdilibA has joined #bitcoin-core-dev
2322017-12-11T12:58:46 <AdilibA> Hi
2332017-12-11T12:59:09 *** CubicEarth has quit IRC
2342017-12-11T13:00:29 *** SopaXorzTaker has joined #bitcoin-core-dev
2352017-12-11T13:00:34 <AdilibA> i want to share a scalling solution that i was thinking about it lately
2362017-12-11T13:00:52 <AdilibA> Is anyone there?
2372017-12-11T13:02:01 *** Danilo_ has joined #bitcoin-core-dev
2382017-12-11T13:03:45 <AdilibA> The solution i was thinking about is by adding compression work in addition to minning work
2392017-12-11T13:04:02 *** danguafer has quit IRC
2402017-12-11T13:04:26 <AdilibA> Add the compression limit is the block size
2412017-12-11T13:05:14 *** Danilo__ has joined #bitcoin-core-dev
2422017-12-11T13:06:57 *** Danilo_ has quit IRC
2432017-12-11T13:07:10 *** Thora1Koelpin has joined #bitcoin-core-dev
2442017-12-11T13:08:19 <AdilibA> I was searching for a compression that is luck based like mining, and isuggest the decomposition of the data to a permutable list of Superior Highly Composite Numbers.
2452017-12-11T13:09:12 *** promag has quit IRC
2462017-12-11T13:09:53 *** yoctopede has quit IRC
2472017-12-11T13:15:30 *** AdilibA has quit IRC
2482017-12-11T13:18:34 *** cheese_ has quit IRC
2492017-12-11T13:20:14 <Provoostenator> AdilibA: I think this is more appropriate for e.g. #bitcoin-wizards or the bitcoin-dev mailinglist. Unless you have a proof-of-concept patch ready to go specifically for the Bitcoin Core client (which this channel is about).
2502017-12-11T13:21:12 *** JackH has quit IRC
2512017-12-11T13:21:53 *** Cheeseo has joined #bitcoin-core-dev
2522017-12-11T13:22:26 *** yoctopede has joined #bitcoin-core-dev
2532017-12-11T13:23:24 *** ghost43 has quit IRC
2542017-12-11T13:24:54 *** promag has joined #bitcoin-core-dev
2552017-12-11T13:28:38 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2562017-12-11T13:29:00 *** ghost43 has joined #bitcoin-core-dev
2572017-12-11T13:29:46 *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
2582017-12-11T13:29:46 *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
2592017-12-11T13:36:22 *** promag has joined #bitcoin-core-dev
2602017-12-11T13:36:32 *** pkx2 has joined #bitcoin-core-dev
2612017-12-11T13:44:10 *** AdilebA has joined #bitcoin-core-dev
2622017-12-11T13:45:45 *** AdilebA has quit IRC
2632017-12-11T14:00:11 *** Victorsueca has quit IRC
2642017-12-11T14:00:40 *** Danilo__ has quit IRC
2652017-12-11T14:01:22 *** Victorsueca has joined #bitcoin-core-dev
2662017-12-11T14:05:47 *** promag has quit IRC
2672017-12-11T14:06:45 *** yoctopede has quit IRC
2682017-12-11T14:07:22 *** promag has joined #bitcoin-core-dev
2692017-12-11T14:10:57 *** Chris_Stewart_5 has quit IRC
2702017-12-11T14:11:36 *** yoctopede has joined #bitcoin-core-dev
2712017-12-11T14:14:40 <morcos> adiabat: can you email me or othwerise send me that fee_estimates.dat. i think it makes sense that happened, but just will take a look to confirm
2722017-12-11T14:15:33 *** intcat has joined #bitcoin-core-dev
2732017-12-11T14:18:52 *** yoctopede has quit IRC
2742017-12-11T14:23:58 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2752017-12-11T14:24:30 *** hoge_ has joined #bitcoin-core-dev
2762017-12-11T14:26:05 *** Cheeseo has quit IRC
2772017-12-11T14:33:25 *** promag has joined #bitcoin-core-dev
2782017-12-11T14:40:11 *** Emcy_ has joined #bitcoin-core-dev
2792017-12-11T14:43:35 *** Emcy has quit IRC
2802017-12-11T14:43:57 *** Emcy has joined #bitcoin-core-dev
2812017-12-11T14:45:53 *** Emcy_ has quit IRC
2822017-12-11T14:48:22 *** alcipir has joined #bitcoin-core-dev
2832017-12-11T14:48:59 *** Emcy has quit IRC
2842017-12-11T14:49:27 *** Chris_Stewart_5 has quit IRC
2852017-12-11T14:52:01 *** timothy has quit IRC
2862017-12-11T14:56:59 <BlueMatt> phantomcircuit: promise? you mean std::promise, or the shared_ptr to the block?
2872017-12-11T14:57:04 *** meshcollider has quit IRC
2882017-12-11T14:59:39 *** timothy has joined #bitcoin-core-dev
2892017-12-11T15:06:57 *** indistylo has quit IRC
2902017-12-11T15:07:18 *** HarlequinFields has joined #bitcoin-core-dev
2912017-12-11T15:17:50 *** intcat has quit IRC
2922017-12-11T15:19:27 <bitcoin-git> [bitcoin] promag opened pull request #11864: wallet: Make fund transaction atomic (master...2017-12-atomic-fundtransaction) https://github.com/bitcoin/bitcoin/pull/11864
2932017-12-11T15:19:51 *** intcat has joined #bitcoin-core-dev
2942017-12-11T15:21:28 <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/f60b4ad57912...8ab6c0b09e4e
2952017-12-11T15:21:29 <bitcoin-git> bitcoin/master 6ba8f30 Gregory Sanders: don't attempt mempool entry for wallet transactions on startup if already in mempool
2962017-12-11T15:21:30 <bitcoin-git> bitcoin/master 6697a70 Gregory Sanders: add test for unconfirmed balance between restarts
2972017-12-11T15:21:30 <bitcoin-git> bitcoin/master 8ab6c0b Wladimir J. van der Laan: Merge #11839: don't attempt mempool entry for wallet transactions on startup if alrâ¦...
2982017-12-11T15:22:47 *** intcat has quit IRC
2992017-12-11T15:23:41 *** intcat has joined #bitcoin-core-dev
3002017-12-11T15:26:22 *** newbie-- has joined #bitcoin-core-dev
3012017-12-11T15:26:47 *** alcipir has quit IRC
3022017-12-11T15:39:54 *** drizztbsd has joined #bitcoin-core-dev
3032017-12-11T15:40:00 *** timothy has quit IRC
3042017-12-11T15:43:01 *** Mattie-161 is now known as Mattie161
3052017-12-11T15:43:23 *** BGL has quit IRC
3062017-12-11T15:45:22 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3072017-12-11T15:48:11 *** promag has quit IRC
3082017-12-11T15:49:25 *** dcousens has quit IRC
3092017-12-11T15:50:31 *** dcousens has joined #bitcoin-core-dev
3102017-12-11T15:56:05 *** Jair has joined #bitcoin-core-dev
3112017-12-11T15:57:28 *** alcipir has joined #bitcoin-core-dev
3122017-12-11T16:05:12 *** alcipir has quit IRC
3132017-12-11T16:07:07 *** DvdKhl has joined #bitcoin-core-dev
3142017-12-11T16:09:11 *** Emcy has joined #bitcoin-core-dev
3152017-12-11T16:11:01 *** intcat has quit IRC
3162017-12-11T16:11:05 *** MarcoFalke has quit IRC
3172017-12-11T16:12:01 *** intcat has joined #bitcoin-core-dev
3182017-12-11T16:12:13 *** MarcoFalke has joined #bitcoin-core-dev
3192017-12-11T16:22:59 *** CubicEarth has joined #bitcoin-core-dev
3202017-12-11T16:23:32 *** emzy has quit IRC
3212017-12-11T16:24:43 *** emzy has joined #bitcoin-core-dev
3222017-12-11T16:27:16 <bitcoin-git> [bitcoin] promag closed pull request #11865: wallet: Improve ReacceptWalletTransactions performance (master...2017-12-improve-reaccept-wallet-transactions) https://github.com/bitcoin/bitcoin/pull/11865
3232017-12-11T16:30:15 *** ghost43 has quit IRC
3242017-12-11T16:30:30 *** ghost43 has joined #bitcoin-core-dev
3252017-12-11T16:30:56 *** intcat has quit IRC
3262017-12-11T16:31:50 *** intcat has joined #bitcoin-core-dev
3272017-12-11T16:41:01 *** Kozuch has quit IRC
3282017-12-11T16:44:34 *** ghost43 has quit IRC
3292017-12-11T16:44:37 *** BGL has joined #bitcoin-core-dev
3302017-12-11T16:44:51 *** ghost43 has joined #bitcoin-core-dev
3312017-12-11T16:50:17 *** alcipir has joined #bitcoin-core-dev
3322017-12-11T16:55:28 *** ghost43 has quit IRC
3332017-12-11T16:55:45 *** ghost43 has joined #bitcoin-core-dev
3342017-12-11T17:04:08 *** Victorsueca has quit IRC
3352017-12-11T17:05:22 *** Victorsueca has joined #bitcoin-core-dev
3362017-12-11T17:05:53 <cluelessperson> I have a serious question. What are thoughts on seperating the Bitcoin Core wallet and Bitcoin Core node?
3372017-12-11T17:06:56 <cluelessperson> Reason I suggest it? 1. Layman cannot be trusted/bothered to run their own nodes by default. 2. I think it will healthily promote SPV development.
3382017-12-11T17:07:42 <cluelessperson> 3. When someone uses multiple wallets, as some users do, they have difficulty switching between the wallets and rescanning, which takes a lot of time
3392017-12-11T17:08:08 <wumpus> isn't there a PR that adds SPV functionality to the wallet?
3402017-12-11T17:08:27 <wumpus> I don't think bringing this up as a discussion topic yet again is productiv
3412017-12-11T17:08:37 *** Ylbam has joined #bitcoin-core-dev
3422017-12-11T17:08:40 <wumpus> it's been discussed zillions of times since 2012 or so
3432017-12-11T17:09:04 <wumpus> every time the conclusion was that yes, it's desirable, if you want it, work toward it
3442017-12-11T17:09:14 <cluelessperson> I understand the frustration. It just keeps coming up for me because I keep getting morons that can't seem to understand how it works in #bitcoin
3452017-12-11T17:09:25 <wumpus> feel free to work on it
3462017-12-11T17:09:34 <cluelessperson> I'll do what I can.
3472017-12-11T17:09:41 <cluelessperson> my skill sets are limited, I'm sorry
3482017-12-11T17:09:49 <cluelessperson> I ask for broader shoulders
3492017-12-11T17:09:51 <wumpus> #10794 is jonasschnelli's PR in that direction
3502017-12-11T17:09:55 <gribble> https://github.com/bitcoin/bitcoin/issues/10794 | Add simple light-client mode (RPC only) by jonasschnelli · Pull Request #10794 · bitcoin/bitcoin · GitHub
3512017-12-11T17:12:43 *** intcat has quit IRC
3522017-12-11T17:14:45 *** intcat has joined #bitcoin-core-dev
3532017-12-11T17:15:32 *** jb55 has joined #bitcoin-core-dev
3542017-12-11T17:26:27 *** DvdKhl has quit IRC
3552017-12-11T17:27:37 *** arubi has quit IRC
3562017-12-11T17:28:32 *** arubi has joined #bitcoin-core-dev
3572017-12-11T17:29:04 *** ghost43 has quit IRC
3582017-12-11T17:29:20 *** ghost43 has joined #bitcoin-core-dev
3592017-12-11T17:33:30 <Provoostenator> cluelessperson: as for multiple wallets: #10740 and #11383
3602017-12-11T17:33:32 <gribble> https://github.com/bitcoin/bitcoin/issues/10740 | [wallet] dynamic loading/unloading of wallets by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
3612017-12-11T17:33:35 <gribble> https://github.com/bitcoin/bitcoin/issues/11383 | Basic Multiwallet GUI support by luke-jr · Pull Request #11383 · bitcoin/bitcoin · GitHub
3622017-12-11T17:34:22 <Provoostenator> There's several pull requests that make small steps in this direction, mostly just improving the code quality and separating stuff better.
3632017-12-11T17:35:26 <cluelessperson> Provoostenator: unfortunately, I'm not a coding expert, and I don't know C++. I have no power here.
3642017-12-11T17:35:34 <cluelessperson> I wish I could actually help
3652017-12-11T17:36:02 <cluelessperson> I'm stuck with documentation and community support. DEVOPs and the like
3662017-12-11T17:36:03 *** indistylo has joined #bitcoin-core-dev
3672017-12-11T17:36:18 <Provoostenator> Well, both can be learned.
3682017-12-11T17:36:35 <Provoostenator> And these other contributions also help, as they take work off the shoulders of developers.
3692017-12-11T17:37:55 <Provoostenator> Or you could stalk your friends with C++ skills and manipulate them into becoming interested in Bitcoin, quitting their current job and helping out :-)
3702017-12-11T17:38:47 *** StopAndDecrypt has quit IRC
3712017-12-11T17:39:17 *** StopAndDecrypt has joined #bitcoin-core-dev
3722017-12-11T17:41:16 *** drizztbsd has quit IRC
3732017-12-11T17:45:22 *** Murch has joined #bitcoin-core-dev
3742017-12-11T17:59:17 <cluelessperson> Provoostenator: I'm trying but I have no path forward
3752017-12-11T17:59:42 <cluelessperson> I'm taking college classes, but not sure where this is leading honestly
3762017-12-11T18:00:09 <alcipir> How long does it take for a seasoned web developer to get into C++?
3772017-12-11T18:02:24 <Randolf> alcipir: It probably depends partly on which languages they already know. For example, if they haven't done anything with Object Oriented Programming, then that will be a learning curve for them too.
3782017-12-11T18:03:09 <alcipir> Hm, I've been doing object-oriented PHP for years now, although I don't like it as a language
3792017-12-11T18:03:14 <alcipir> also know a bit of Java and C#
3802017-12-11T18:03:31 <alcipir> but C++ seems pretty daunting at first, seems like it changes a lot over time
3812017-12-11T18:04:24 <Randolf> alcipir: I suspect that the folks in the #c++ channel can probably be very helpful to getting you started based on what you already have a background in. :)
3822017-12-11T18:05:27 <Randolf> alcipir: My suggestion is to learn C++ first, and then learn about programming Bitcoin/blockchain. The reason is that both have learning curves that are probably better-studied separately.
3832017-12-11T18:05:39 <alcipir> I see, thanks for the tip :)
3842017-12-11T18:05:44 <Randolf> You're welcome.
3852017-12-11T18:09:59 *** lrvick has quit IRC
3862017-12-11T18:10:01 *** HarlequinFields has quit IRC
3872017-12-11T18:10:02 *** Victorsueca has quit IRC
3882017-12-11T18:10:43 *** Dizzle has joined #bitcoin-core-dev
3892017-12-11T18:11:08 *** paveljanik has joined #bitcoin-core-dev
3902017-12-11T18:11:08 *** paveljanik has joined #bitcoin-core-dev
3912017-12-11T18:11:22 *** Victorsueca has joined #bitcoin-core-dev
3922017-12-11T18:13:28 <Provoostenator> acipir: that's roughly my background as well, although I did dabble in C(++) 15 years ago and worked a lot with ObjectiveC. Here's some book recommendations depending on your background: https://stackoverflow.com/a/388282
3932017-12-11T18:14:44 <sipa> i think the discussion is getting a bit offtopic
3942017-12-11T18:16:27 *** mrfrasha has joined #bitcoin-core-dev
3952017-12-11T18:17:14 *** jamesob has joined #bitcoin-core-dev
3962017-12-11T18:18:59 <alcipir> thanks Provoostenator, and sorry for the offtopic discussion
3972017-12-11T18:22:58 *** lrvick has joined #bitcoin-core-dev
3982017-12-11T18:24:59 *** intcat has quit IRC
3992017-12-11T18:26:15 <michagogo> Why do we still have a "Pay only the required fee of 1 satoshi/byte" checkbox?
4002017-12-11T18:26:18 *** intcat has joined #bitcoin-core-dev
4012017-12-11T18:27:28 <michagogo> I mean, now that we have RBF, it's probably not quite as bad as it used to be, but it still seems like it's likely to be misleading
4022017-12-11T18:28:12 <michagogo> Yeah, it's under the Custom radio button and not under Recommended, but it feels like it's saying that that's okay and has a chance at working
4032017-12-11T18:28:51 *** mrfrasha has quit IRC
4042017-12-11T18:34:21 *** mrfrasha has joined #bitcoin-core-dev
4052017-12-11T18:37:24 *** Szadek has joined #bitcoin-core-dev
4062017-12-11T18:37:43 <wumpus> I don't know, feel free to file a PR to remove it and see if there's interest / pushback
4072017-12-11T18:38:42 <wumpus> by far most people will simply use the recommended fee (which is the default), and those that don't generally know better what they're doing, so I doubt it matters much
4082017-12-11T18:40:51 *** laurentmt has quit IRC
4092017-12-11T18:43:31 *** CubicEarth has quit IRC
4102017-12-11T18:47:38 *** quantbot has joined #bitcoin-core-dev
4112017-12-11T18:55:18 *** emzy has quit IRC
4122017-12-11T18:55:18 *** emzy has joined #bitcoin-core-dev
4132017-12-11T18:58:21 *** jtimon has joined #bitcoin-core-dev
4142017-12-11T19:00:01 *** JackH has joined #bitcoin-core-dev
4152017-12-11T19:00:42 *** CubicEarth has joined #bitcoin-core-dev
4162017-12-11T19:05:34 <gmaxwell> Bluematt: re: transaction delayed bundles:
4172017-12-11T19:05:34 <gmaxwell> re: for wallet encryption, I think you can just sign the current best batch when each rpc comes in, so you don't need
4182017-12-11T19:05:37 <gmaxwell> to keep the key around. The downside is that it can't use the fee-estimation at the point of send, but that seems like
4192017-12-11T19:05:40 <gmaxwell> a small loss.
4202017-12-11T19:05:42 <gmaxwell> Interface wise, you'll need to return some kind of identifier that the wallet can use to tell you if a payment was made.
4212017-12-11T19:05:45 <gmaxwell> BlueMatt: I don't think there is a reason to make the standard rpcs do this, just add new ones: "bundlesend" (works
4222017-12-11T19:05:48 <gmaxwell> like sendmany, but takes a maximum waittime argument) "bundleabort" (can cancel a transaction using a handle returned
4232017-12-11T19:05:52 <gmaxwell> by bundlesend) "bundleforce" (forces the current bundle to send now) or something... and a behavior that sends N
4242017-12-11T19:05:54 <gmaxwell> seconds after the last addition, or when the first timeout is hit.
4252017-12-11T19:05:57 <gmaxwell> unless it would really be a burden to change the rpc calls their software is making... but I think thats unavoidable
4262017-12-11T19:06:00 <gmaxwell> since you can't return a txid.
4272017-12-11T19:06:03 <gmaxwell> For a while I've wanted a standardized signed payment confirmation code, basically a signature with some well known key
4282017-12-11T19:06:06 <gmaxwell> that says "I promise to pay X btc to address Y", which would be a potential candidate for what gets returned, but
4292017-12-11T19:06:09 <gmaxwell> perhaps too much scope creep.
4302017-12-11T19:06:33 <gmaxwell> One thing perhaps to keep in mind is that the names of the RPCs should be short and easy because probably we'd like to make the bundle based method the default and standard method.
4312017-12-11T19:06:54 <BlueMatt> yes, thats probably scope creep
4322017-12-11T19:07:10 <BlueMatt> but, generally, I think these could be added quite simply to large benefit of some users
4332017-12-11T19:07:55 <gmaxwell> One reason some large users have given me for not using their own aggregation (parties easily big enough do implement their own) was that they want txids to give to users that they can immediately look up on block explorers.
4342017-12-11T19:08:06 <jonasschnelli> wumpus: https://github.com/bitcoin/bitcoin/pull/11845
4352017-12-11T19:08:18 <BlueMatt> worth reaching out to people who use bitcoin core's wallet in reasonable volume to ask what they'd want from such an interface
4362017-12-11T19:08:19 <jonasschnelli> The key links to btcplt.org (Bitcoin Platinum)
4372017-12-11T19:08:30 <BlueMatt> gmaxwell: yea, that really sucks, dunno how to get away from it except for rbf, sadly
4382017-12-11T19:08:43 <gmaxwell> BlueMatt: with the signed code I just suggested.
4392017-12-11T19:08:48 <BlueMatt> gmaxwell: an independantly-really-useful project which someone should do is go test what the ux is on wallets when you receive rbf txn
4402017-12-11T19:08:48 <jonasschnelli> Not sure if we want a key leading to the Bitcoin Platinum project in our repository,... could be missued for advertising?
4412017-12-11T19:08:55 <BlueMatt> gmaxwell: yes, but block explorers wont support that for...20 years
4422017-12-11T19:09:17 <gmaxwell> BlueMatt: meh, bc.i had sorta support for bech32 addresses when segwit activated.
4432017-12-11T19:09:39 <gmaxwell> some kind of signmessage thing wouldn't be a big deal to support, doesn't require a blockchain to back it.
4442017-12-11T19:09:40 <BlueMatt> gmaxwell: I'm super skeptical, but would love to be proven wrong....
4452017-12-11T19:09:51 <BlueMatt> true, could signmessage magic
4462017-12-11T19:09:56 <gmaxwell> I mean, any of us could also put up little dumb js pages for that.
4472017-12-11T19:10:30 <Provoostenator> jonasschnelli: would it make sense to ask for plain text keys instead of binary ones, so this sort of thing is easier to spot? (regardless of whether this domain matters)
4482017-12-11T19:10:33 <gmaxwell> It would just be a reciept that a person could save and use to prove to others when their counterparty doesn't make good on a promise to pay.
4492017-12-11T19:10:38 *** Victorsueca has quit IRC
4502017-12-11T19:10:47 <BlueMatt> (obviiously getting wallets to have reasonable ux when receiving rbf txn would be independantly incredibly helpful - how many wallets spend unconfirmed/unconfirmable/conflicting txn if you receive a rbf-bumped tx?)
4512017-12-11T19:10:53 <jonasschnelli> Provoostenator: no... I don't think so...
4522017-12-11T19:11:04 <jonasschnelli> Provoostenator: there is always an email (or pretty much always) attached...
4532017-12-11T19:11:28 <BlueMatt> gmaxwell: true....I suppose if we put up a page for it that may also be sufficient, I guess people dont care *what* block explorer shows it, as long as they can link to one that does
4542017-12-11T19:11:28 <gmaxwell> BlueMatt: yes and we should keep RBF in mind when doing the batch interface, the batch interface should be specified so that it's okay for it to RBF anything you put through it.
4552017-12-11T19:11:31 <Provoostenator> Nvm, you can't see the email in a .asc file either; just need to import it to see.
4562017-12-11T19:11:52 *** Victorsueca has joined #bitcoin-core-dev
4572017-12-11T19:11:53 <BlueMatt> yes
4582017-12-11T19:11:58 *** HarlequinFields has joined #bitcoin-core-dev
4592017-12-11T19:12:08 *** HarlequinFields has quit IRC
4602017-12-11T19:12:18 *** HarlequinFields has joined #bitcoin-core-dev
4612017-12-11T19:12:21 <gmaxwell> BlueMatt: batch interface's spec should be "will get a payment made of the specified amounts to the specified addresses accomplished eventually"
4622017-12-11T19:12:23 <BlueMatt> one thing we should do is reach out to "industry" folks regarding potential apis here (batching/whether they'd be happy with a signmessage-equivalent?)
4632017-12-11T19:12:46 <gmaxwell> well I think they've never thought of these things, so we'd have to propose them.
4642017-12-11T19:13:28 <BlueMatt> yes, thats my point :p
4652017-12-11T19:13:56 *** woozyn has joined #bitcoin-core-dev
4662017-12-11T19:14:05 *** CubicEarth has quit IRC
4672017-12-11T19:16:50 <gmaxwell> oh, rpc I missed: bundletxid takes a bundle handle and tells you the txid it eventually issued.. maybe also if it was confirmed and in what block.
4682017-12-11T19:18:03 <BlueMatt> well bundletx verbose=X
4692017-12-11T19:18:31 <gmaxwell> rpcs that return all txn like listtransactions kinda stink.
4702017-12-11T19:18:56 <BlueMatt> i mean get the tx for the bundle in raw (or hex, or txid) form
4712017-12-11T19:19:08 *** intcat has quit IRC
4722017-12-11T19:19:12 <gmaxwell> ah.
4732017-12-11T19:19:38 <sipa> is there a need to support multiple bundles simultaneously?
4742017-12-11T19:19:56 <BlueMatt> little reason not to, but probably not?
4752017-12-11T19:19:57 *** intcat has joined #bitcoin-core-dev
4762017-12-11T19:20:32 <sipa> my thinking was that there'd just be a single set of output/amount pairs that are in flight
4772017-12-11T19:20:50 <sipa> and any time you update it, a new transaction is created
4782017-12-11T19:21:03 <sipa> which is guaranteed to conflict with earlier transactions
4792017-12-11T19:21:16 <BlueMatt> you mean and not announce them?
4802017-12-11T19:21:21 <gmaxwell> the guarenteed to conflict will result in suboptimal coin selection.
4812017-12-11T19:21:26 <BlueMatt> rbf would have to be optional given receiving rbf txn right now sucks
4822017-12-11T19:21:40 <sipa> gmaxwell: sure
4832017-12-11T19:21:48 <gmaxwell> BlueMatt: I described above creating the tx at RPC not announce time.
4842017-12-11T19:21:56 <adiabat> related to pre-signing a bunch of txs with increasing fee rates, what if you have incremental locktimes on them?
4852017-12-11T19:22:06 <gmaxwell> sipa: why bother with a guarentee to conflict, if you give the user no access to the txn itself until announce time?
4862017-12-11T19:22:10 <BlueMatt> i see no reason to not wait, except for wallet encryption, but I'd prefer to decrypt-at-send-time than at-add-output time, no?
4872017-12-11T19:22:11 *** Scooooobydooo has joined #bitcoin-core-dev
4882017-12-11T19:22:19 <adiabat> would it then be possible to have nodes relay the txs even if they're not-yet-minable?
4892017-12-11T19:22:43 <sipa> gmaxwell: well it would need to conflict at least with broadcasted transactions
4902017-12-11T19:22:48 <gmaxwell> adiabat: setting locktimes on precreated replacements is the obvious thing to do, suggested every time it has come up.
4912017-12-11T19:23:08 <adiabat> gmaxwell: ok what's the catch...?
4922017-12-11T19:23:20 <gmaxwell> adiabat: relaying a non-mingable transaction is an immediate and nasty DOS vector... what value do you see in that?
4932017-12-11T19:23:26 <BlueMatt> some people dont want to do rbf cause the client-side wallets may handle it like garbage
4942017-12-11T19:23:29 <sipa> gmaxwell: in my earlier descriptions of this idea there was no separation between creation of the transaction and broadcastng
4952017-12-11T19:23:50 <gmaxwell> adiabat: there is no catch, if bitcoin core ever does replacement fully I assume it'll presign with locktimes.
4962017-12-11T19:24:06 <sipa> but it does make sense - you may want to perform multiple updates frequently, but only occasionally issue a new transaction
4972017-12-11T19:24:12 <adiabat> gmaxwell: value is that wallets can fire-and-forget; DoS is the issue but feels like it could be managed
4982017-12-11T19:24:27 <Provoostenator> BlueMatt: I suspect that if enough wallets start actually using RBF, other wallets will stop handling them like garbage. It's often a matter of educating UX folks and developers.
4992017-12-11T19:24:43 <BlueMatt> Provoostenator: agreed, but also a chicken-and-egg issue there
5002017-12-11T19:24:53 *** CubicEarth has joined #bitcoin-core-dev
5012017-12-11T19:25:02 <gmaxwell> adiabat: best of luck with that.
5022017-12-11T19:25:21 <BlueMatt> sipa: wait, how do you propose it working if you create a new tx every time you add an output and broadcast immediately and *dont* use rbf?
5032017-12-11T19:25:24 <adiabat> gmaxwell: heh :) Yeah it's hard to not get banned
5042017-12-11T19:25:35 <BlueMatt> (hell, even with rbf you have lots of annoying corner-cases)
5052017-12-11T19:25:40 <sipa> BlueMatt: of course it would RBF
5062017-12-11T19:25:49 <BlueMatt> sipa: the whole point was to make rbf optional..........
5072017-12-11T19:26:01 <sipa> maybe we're talking about something unrelated then :)
5082017-12-11T19:26:04 <BlueMatt> see discussion above...
5092017-12-11T19:26:21 *** paveljanik has quit IRC
5102017-12-11T19:26:21 <BlueMatt> a tx bundle api would have to have rbf be optional
5112017-12-11T19:26:28 <sipa> meh
5122017-12-11T19:26:34 <gmaxwell> sipa: the point of this discussion was to enable parties to sendmany.
5132017-12-11T19:26:36 <BlueMatt> if you have rbf on you can get instant-sends that just get replaced, but no one (right now) would use it if its only rbf
5142017-12-11T19:26:56 <gmaxwell> Right now too many people use txid as an effective unique key for a payment.. you utterly break stuff by rbfing.
5152017-12-11T19:26:59 <BlueMatt> sipa: feel free to go help user-level wallets fix their rbf-receive ux
5162017-12-11T19:27:12 <sipa> fair
5172017-12-11T19:27:27 *** Victor_sueca has joined #bitcoin-core-dev
5182017-12-11T19:27:46 <BlueMatt> rbf appears to work pretty sell *sending* to services, but a service sending rbf to a user-side wallet....bad ux
5192017-12-11T19:27:48 <sipa> i guess i was thinking about a longer term thing for when RBFing is not an issue anymore, and people have stopped relying on txids for unconfirmed transactions
5202017-12-11T19:27:53 *** Szadek has quit IRC
5212017-12-11T19:28:03 <BlueMatt> no, I'm talking about building an api now...not something no one will use
5222017-12-11T19:28:11 <sipa> okay, ignore e
5232017-12-11T19:28:22 <adiabat> gmaxwell: apologies if off-topic or already discussed- what if policy was accept future locktimed tx but only if it's a fee bump of existing mempool tx?
5242017-12-11T19:28:51 <BlueMatt> adiabat: doesnt ln have like a model where folks run servers which auto-broadcast in the future? just piggy back on them
5252017-12-11T19:28:57 <BlueMatt> no need to relay it in bitcoin p2p net?
5262017-12-11T19:29:12 <adiabat> yup, asking because I'm working on similar stuff
5272017-12-11T19:29:30 <adiabat> Hmm... OK so maybe code LN stuff to accept not-yet-OK RBF txs instead?
5282017-12-11T19:29:55 <sipa> accepting things into your mempool which can't confirm soon undermines its DoS protection
5292017-12-11T19:30:10 <gmaxwell> adiabat: that gives an attacker zero-cost n-fold inflation node node bandwidth/cpu/memory... (make the initial one enough to confirm right away, make N bumps)
5302017-12-11T19:30:20 *** Victorsueca has quit IRC
5312017-12-11T19:30:21 <BlueMatt> yea, I mean I'd strongly suggest if you're gonna run a network of servers/users providing services to montior and announce txn later to add an option to broadcast *anything* later
5322017-12-11T19:30:22 <sipa> as we rely on assuming that everything in the mempool will eventually be either confirmed or replaced with something paying a higher fee
5332017-12-11T19:30:29 <BlueMatt> then its a generic service
5342017-12-11T19:30:32 <adiabat> right, for small N might be doable if nodes opt-in
5352017-12-11T19:30:35 <Provoostenator> BlueMatt: good point to distinguish between "merchant" services and consumer wallets when it comes to RBF. Although I think it's very useful for sending money between people who reasonable trust eachother; "let me know if you need me to bump this"
5362017-12-11T19:30:49 <gmaxwell> adiabat: I think it's not reasonable to have every node in the general p2p network handling this, why not just have special transaction queue nodes that will handle this?
5372017-12-11T19:31:14 <BlueMatt> Provoostenator: well my concern is ux for average users...if I'm sending to someone I know understands bitcoin, fine, no issue, if its some guy who's receiving a withdraw from an atm/their exchange, they may be very confused
5382017-12-11T19:31:23 <adiabat> gmaxwell: I agree; I'm mainly thinking about the logistics of different nodes / codebases
5392017-12-11T19:31:52 <gmaxwell> there is no need for 100,000 nodes to queue up txn that will likely never confirm.... just having a couple handle it would be sufficient.
5402017-12-11T19:32:04 <adiabat> easy enough to have a website which says "give your future-dated RBF txs" and has a captcha or something
5412017-12-11T19:32:46 <BlueMatt> or add it to ln nodes? dont they have some ability to do similar things?
5422017-12-11T19:33:00 <BlueMatt> might as well let them do it for any txn with payment of 5 satoshis over ln or so?
5432017-12-11T19:33:10 <adiabat> right now LN nodes don't have actual tx storage for other nodes
5442017-12-11T19:33:20 <adiabat> but it's something that could be added
5452017-12-11T19:33:45 <adiabat> I have been looking at bumping fees for funding channels and it's a little tricky due to multisig / multiple parties
5462017-12-11T19:34:51 *** dcousens has quit IRC
5472017-12-11T19:35:06 *** dcousens has joined #bitcoin-core-dev
5482017-12-11T19:35:24 <Provoostenator> BlueMatt: what's the implication of that for #11605? In particular, wouldn't that make the case for not making RBF a default in RPC, because we don't want every ATM out there to start using this just yet?
5492017-12-11T19:35:28 <gribble> https://github.com/bitcoin/bitcoin/issues/11605 | [Wallet] Enable RBF by default in QT by Sjors · Pull Request #11605 · bitcoin/bitcoin · GitHub
5502017-12-11T19:35:35 <Provoostenator> (every ATM that uses the Core wallet)
5512017-12-11T19:35:58 <gmaxwell> Provoostenator: hm? there is no problem signaling RBF if you don't make use of it.
5522017-12-11T19:36:03 <gmaxwell> The problems arise when you make use of it.
5532017-12-11T19:36:07 <BlueMatt> Provoostenator: I mean that would be my thought, which is what I put in that pr anyway, but worth asking morcos and jnewbery since they objected?
5542017-12-11T19:36:15 <BlueMatt> yea, ok, that too, if you dont use it it doesnt matter
5552017-12-11T19:36:18 <gmaxwell> The issue for the batching thing is that if it used RBF it would immeidately make use of it.
5562017-12-11T19:36:19 <Provoostenator> Ok, that's a good point. Wallets indeed suck even more at that.
5572017-12-11T19:36:39 <Provoostenator> They complain it's a double spend, might even mess up the balance.
5582017-12-11T19:36:59 <gmaxwell> though on reflection even if your batching thing can RBF, it shouldn't do so eagerly, since it'll pay high fees since the bumps have to increase fees.
5592017-12-11T19:37:29 <BlueMatt> yes, exactly, batching rbf isnt quite supported by the current restrictions on rbf...maybe be worth exploring reducing those restrictions if people have a desire for it
5602017-12-11T19:37:31 <gmaxwell> but still, flagging rbf is pretty much harmless, I believe electrum does this by default already without incident...
5612017-12-11T19:37:39 *** quantbot_ has joined #bitcoin-core-dev
5622017-12-11T19:38:05 <gmaxwell> BlueMatt: I dunno, if anything current RBF restrictions are too lax because mempool minfee is unrealistically low.
5632017-12-11T19:39:07 <BlueMatt> yea, well possibly minfee needs to be higher with the incremental/relay fee lower for rbf? dunno, worth exploring
5642017-12-11T19:39:41 *** dcousens has quit IRC
5652017-12-11T19:40:25 <Provoostenator> Do we have an estimate of how often fee increases are used in the wild currently? I find it useless in both GreenWallet and QT, because it doesn't let you pick your own amount, and the cheapest option is usually much too expensive.
5662017-12-11T19:40:55 *** dcousens has joined #bitcoin-core-dev
5672017-12-11T19:41:01 <Provoostenator> Like I make a tx with a â¬0.50 fee and it says the minimum for a fee bump is â¬25.
5682017-12-11T19:41:08 *** quantbot has quit IRC
5692017-12-11T19:41:22 <BlueMatt> that....doesnt sound right
5702017-12-11T19:41:47 <BlueMatt> oh, yea, greenaddress' feebump is really annoying
5712017-12-11T19:41:50 <gmaxwell> for greenaddress IIRC it only currently supports one bump, so it only offers it at whatever the shortest fee estimate is.
5722017-12-11T19:41:50 <Provoostenator> I had to use some AngularJS javascript console voodoo to make GreenWallet behave. And with Core I already have a TODO to improve this.
5732017-12-11T19:41:51 *** quantbot_ has quit IRC
5742017-12-11T19:41:52 *** intcat has quit IRC
5752017-12-11T19:42:06 <BlueMatt> gmaxwell: no, it offers several, but they're all relatively short
5762017-12-11T19:42:50 *** intcat has joined #bitcoin-core-dev
5772017-12-11T19:43:01 <Provoostenator> https://twitter.com/Provoost/status/925245638379483137
5782017-12-11T19:43:41 <gmaxwell> Provoostenator: the bumpfee in bitcoin core however lets you set whatever target you want AFAIR.
5792017-12-11T19:44:02 *** Cheeseo has joined #bitcoin-core-dev
5802017-12-11T19:44:09 <Provoostenator> gmaxwell: correct, so my TODO is about allow the UI to do the same. Probably by reusing the send screen, hiding all elements except the fee selection.
5812017-12-11T19:44:32 <Provoostenator> (and enforcing the correct minimum, etc)
5822017-12-11T19:44:39 <gmaxwell> you might want to also do something to handle the minim..right
5832017-12-11T19:44:40 <adiabat> bitcoin-qt bump fee only gives you one option though; cli lets you set whatever you want
5842017-12-11T19:44:58 <gmaxwell> I'd forgotten we had anything in the GUI yet.
5852017-12-11T19:45:15 <adiabat> you can right click on txs and there's an "increase fee" option
5862017-12-11T19:45:16 <Provoostenator> I'm trying to Make QT Great Again :-)
5872017-12-11T19:45:21 <gmaxwell> it's still relatively useless due to not being able to change the input set.
5882017-12-11T19:45:23 <adiabat> brings up a modal with OK / cancel
5892017-12-11T19:47:10 <Provoostenator> Yes, that's the other contraint I suppose. I guess the max fee is constrained by the amount of change for the original tx?
5902017-12-11T19:48:13 <Provoostenator> I'm not going to mess with coin selection, but for RBF, it might make sense to try and overshoot by the worst case fee, if there is an input available.
5912017-12-11T19:50:47 <gmaxwell> uhg. no... the correct thing to do is to just drop the same-inputs restriction.
5922017-12-11T19:51:16 <gmaxwell> it was just done that way to make it faster to implement, but it's a bad restriction.
5932017-12-11T19:51:20 <Provoostenator> That does sound cleaner. Is that restriction part of the BIP?
5942017-12-11T19:51:25 <gmaxwell> absolutely not
5952017-12-11T19:51:56 *** Chris_Stewart_5 has quit IRC
5962017-12-11T19:51:59 *** StopAndDecrypt has quit IRC
5972017-12-11T19:52:01 <Provoostenator> Ok, so the first step there would be to change bumpfee RPC to let go of same-input?
5982017-12-11T19:52:30 *** StopAndDecrypt has joined #bitcoin-core-dev
5992017-12-11T19:52:31 *** StopAndDecrypt has quit IRC
6002017-12-11T19:52:31 *** StopAndDecrypt has joined #bitcoin-core-dev
6012017-12-11T19:52:46 *** DvdKhl has joined #bitcoin-core-dev
6022017-12-11T19:52:51 <Provoostenator> But somehow track what you've used, because I assuem there has to be overlap in inputs.
6032017-12-11T19:52:58 <Provoostenator> (between all versions)
6042017-12-11T19:53:00 <gmaxwell> Probably easiest to let it add additional inputs, this requires plumbing through mandatory inputs to the coin selection logic.
6052017-12-11T19:53:40 <gmaxwell> technically they merely needs to be an overlap. But it's simpler to superset and I think hardly worse.
6062017-12-11T19:53:50 <gmaxwell> Supersetting is better for privacy.
6072017-12-11T19:54:52 *** helo has quit IRC
6082017-12-11T19:55:53 *** helo has joined #bitcoin-core-dev
6092017-12-11T19:56:44 <Provoostenator> And the wallet keeps all previous versions around and knows which ones they are? (doesn't matter in the superset case)
6102017-12-11T19:57:15 *** booyah has quit IRC
6112017-12-11T19:57:41 <gmaxwell> Thats why the superset case is easier to implement.
6122017-12-11T19:57:48 <Provoostenator> Supersetting in combination with my idea above of overshooting the initial selection?
6132017-12-11T19:58:25 <Provoostenator> (though that can always be done later)
6142017-12-11T19:59:14 <gmaxwell> there is no reason to overshoot the initial.
6152017-12-11T19:59:57 <gmaxwell> we should be trying to avoid producing dusty change (e.g. change in value comparible to fees)
6162017-12-11T20:00:12 *** ghost43 has quit IRC
6172017-12-11T20:00:41 *** MarcoFalke has quit IRC
6182017-12-11T20:00:55 <Provoostenator> My rational was to make bumping cheaper in the super set scenario, because you don't need to add an extra input. But I see your point about creating dust.
6192017-12-11T20:01:39 *** SopaXorzTaker has quit IRC
6202017-12-11T20:02:04 <gmaxwell> well you'll pay the fees for that extra input eventually, so it's not that bad to add it.
6212017-12-11T20:02:23 <gmaxwell> the cost of the extra input is just the difference in the feerate between now and when you might use it later.
6222017-12-11T20:02:37 *** MarcoFalke has joined #bitcoin-core-dev
6232017-12-11T20:09:30 *** ghost43 has joined #bitcoin-core-dev
6242017-12-11T20:09:40 *** woozyn has quit IRC
6252017-12-11T20:11:14 <luke-jr> gmaxwell: but you need to cover the cost of the data/weight for the first tx as well?
6262017-12-11T20:11:32 <luke-jr> not sure it matters much in practice I guess
6272017-12-11T20:13:52 *** Victor_sueca has quit IRC
6282017-12-11T20:15:03 *** Victor_sueca has joined #bitcoin-core-dev
6292017-12-11T20:16:49 *** intcat has quit IRC
6302017-12-11T20:17:10 <Provoostenator> Probably not when fees are at a level where you actually need RBF.
6312017-12-11T20:17:39 *** intcat has joined #bitcoin-core-dev
6322017-12-11T20:17:54 <Provoostenator> At what point would you expect most node operators to increase the minimum relay fee?
6332017-12-11T20:18:41 *** tripleslash has joined #bitcoin-core-dev
6342017-12-11T20:23:01 <gmaxwell> Provoostenator: we don't expect anyone to increase the minimum relay fee, we expect it to increase automatically.
6352017-12-11T20:23:27 <gmaxwell> unfortunately it's not, seemingly because the mempool is too big.
6362017-12-11T20:25:56 <sipa> Provoostenator: do you mean the minimum relay fee (the fee needed to get into the mempool at all) or the discard rate (the fee increment needed for replacing) ?
6372017-12-11T20:26:25 <sipa> the first is controlled by the mempool limiting; the second is just a configurable constant
6382017-12-11T20:26:37 <sipa> (luke-jr was talking about the second)
6392017-12-11T20:31:44 *** intcat has quit IRC
6402017-12-11T20:32:42 *** intcat has joined #bitcoin-core-dev
6412017-12-11T20:40:46 <morcos> gmaxwell: it got quite high before the weekend, i think 40 sat/B
6422017-12-11T20:42:02 <morcos> is there any reason that resendwallettransactions needs to be a hidden RPC only used for testing?
6432017-12-11T20:42:23 <morcos> doesn't it seem kind of useful to be able to fully create and locally accept transactions, but not broadcast them until ready
6442017-12-11T20:42:59 <morcos> is it just a privacy concern?
6452017-12-11T20:43:44 <morcos> this is partly in response to the ongoing discussion in #10247 right now
6462017-12-11T20:43:46 <gribble> https://github.com/bitcoin/bitcoin/issues/10247 | cost too many fees? · Issue #10247 · bitcoin/bitcoin · GitHub
6472017-12-11T20:43:55 <gmaxwell> you mean turn off wallet broadcast and trigger broadcasting yourself?
6482017-12-11T20:44:25 <morcos> yeah exactly
6492017-12-11T20:44:31 <gmaxwell> we probably need to add a flag in the wallet to track if unconfirmed txn has been seen in the mempool, and show it in the GUI, to avoid users footgunning by never broadcasting.
6502017-12-11T20:44:49 <gmaxwell> but I think it's fine, personally I always run with broadcasting off.
6512017-12-11T20:45:20 <instagibbs> do you just sendraw when ready?
6522017-12-11T20:45:41 <morcos> ah, i suppose sendraw accomplish what i wanted to suggest pretty well
6532017-12-11T20:47:46 <phantomcircuit> personally i disable internet when i want to do that...
6542017-12-11T20:48:26 *** cheese_ has joined #bitcoin-core-dev
6552017-12-11T20:50:59 *** Kozuch has joined #bitcoin-core-dev
6562017-12-11T21:07:09 * luke-jr wonders why the GUI is blocked until rescan finishes
6572017-12-11T21:07:40 *** _biO_ has joined #bitcoin-core-dev
6582017-12-11T21:10:42 *** alcipir has quit IRC
6592017-12-11T21:11:12 *** indistylo has quit IRC
6602017-12-11T21:11:13 *** promag has joined #bitcoin-core-dev
6612017-12-11T21:12:32 *** promag has quit IRC
6622017-12-11T21:13:49 *** intcat has quit IRC
6632017-12-11T21:13:50 *** booyah has joined #bitcoin-core-dev
6642017-12-11T21:15:08 *** intcat has joined #bitcoin-core-dev
6652017-12-11T21:16:43 *** intcat has quit IRC
6662017-12-11T21:18:02 *** intcat has joined #bitcoin-core-dev
6672017-12-11T21:25:48 *** StopAndDecrypt has quit IRC
6682017-12-11T21:26:15 *** StopAndDecrypt has joined #bitcoin-core-dev
6692017-12-11T21:26:16 *** StopAndDecrypt has quit IRC
6702017-12-11T21:26:16 *** StopAndDecrypt has joined #bitcoin-core-dev
6712017-12-11T21:27:09 *** go1111111 has quit IRC
6722017-12-11T21:28:11 *** promag has joined #bitcoin-core-dev
6732017-12-11T21:30:26 *** StopAndDecrypt has quit IRC
6742017-12-11T21:30:44 *** StopAndDecrypt has joined #bitcoin-core-dev
6752017-12-11T21:30:45 *** StopAndDecrypt has quit IRC
6762017-12-11T21:30:45 *** StopAndDecrypt has joined #bitcoin-core-dev
6772017-12-11T21:31:06 *** promag has quit IRC
6782017-12-11T21:33:39 *** Victor_sueca has quit IRC
6792017-12-11T21:34:52 *** Victor_sueca has joined #bitcoin-core-dev
6802017-12-11T21:35:21 *** atroxes has quit IRC
6812017-12-11T21:36:42 *** atroxes has joined #bitcoin-core-dev
6822017-12-11T21:42:53 *** dermoth has quit IRC
6832017-12-11T21:43:18 *** ekrok has quit IRC
6842017-12-11T21:43:20 *** dermoth has joined #bitcoin-core-dev
6852017-12-11T21:47:05 *** Emcy_ has joined #bitcoin-core-dev
6862017-12-11T21:47:10 *** Kozuch_ has joined #bitcoin-core-dev
6872017-12-11T21:47:27 *** StopAndDecrypt has quit IRC
6882017-12-11T21:48:06 *** _parts_ has joined #bitcoin-core-dev
6892017-12-11T21:48:40 *** Chris_Stewart_5 has joined #bitcoin-core-dev
6902017-12-11T21:49:39 *** [\\\] has joined #bitcoin-core-dev
6912017-12-11T21:50:49 *** ekrok has joined #bitcoin-core-dev
6922017-12-11T21:50:52 <jb55> morcos: I'm about to remove the InMempool() check from AbandonTransaction on my local node, is there any good reason why that's there?
6932017-12-11T21:51:21 *** Scooooobydooo has quit IRC
6942017-12-11T21:51:33 *** eenoch_ has joined #bitcoin-core-dev
6952017-12-11T21:51:33 *** Lauda_ has joined #bitcoin-core-dev
6962017-12-11T21:51:36 *** wump has joined #bitcoin-core-dev
6972017-12-11T21:51:48 *** c40d9b0753a91f40 has joined #bitcoin-core-dev
6982017-12-11T21:52:04 *** scoooobydooo has joined #bitcoin-core-dev
6992017-12-11T21:52:23 *** mr_burdell_ has joined #bitcoin-core-dev
7002017-12-11T21:52:39 <sipa> jb55: if your own node has it in its mempool, it's very likely other nodes do too, in which case the effect won't accomplish much
7012017-12-11T21:53:00 <sipa> you could try to double-spend the transaction, but it may not get relayed by other nodes, for example
7022017-12-11T21:53:09 <jb55> I've just had a tx that's been around for a month and it looks like my node keeps rebroadcasting it?
7032017-12-11T21:55:12 *** molz has joined #bitcoin-core-dev
7042017-12-11T21:55:14 *** Lightsword_ has joined #bitcoin-core-dev
7052017-12-11T21:55:25 *** morcos_ has joined #bitcoin-core-dev
7062017-12-11T21:56:02 *** achow101_ has joined #bitcoin-core-dev
7072017-12-11T21:56:03 <jtimon> MarcoFalke: what needs to be done for https://github.com/bitcoin/bitcoin/pull/8994/commits/52f6f43968595a769b109b9b6987ab03275c4a9d#r153922809 ?
7082017-12-11T21:56:25 *** Kozuch has quit IRC
7092017-12-11T21:56:25 *** HarlequinFields has quit IRC
7102017-12-11T21:56:25 *** tripleslash has quit IRC
7112017-12-11T21:56:25 *** Emcy has quit IRC
7122017-12-11T21:56:25 *** d9b4bef9 has quit IRC
7132017-12-11T21:56:25 *** eck has quit IRC
7142017-12-11T21:56:25 *** mr_burdell has quit IRC
7152017-12-11T21:56:26 *** Lauda has quit IRC
7162017-12-11T21:56:26 *** wumpus has quit IRC
7172017-12-11T21:56:26 *** mlz has quit IRC
7182017-12-11T21:56:26 *** c40d9b0743a91f40 has quit IRC
7192017-12-11T21:56:26 *** morcos has quit IRC
7202017-12-11T21:56:26 *** _parts has quit IRC
7212017-12-11T21:56:26 *** Lightsword has quit IRC
7222017-12-11T21:56:26 *** eenoch has quit IRC
7232017-12-11T21:56:26 *** achow101 has quit IRC
7242017-12-11T21:56:26 *** GAit has quit IRC
7252017-12-11T21:56:26 *** mr_burdell_ is now known as mr_burdell
7262017-12-11T21:56:27 *** morcos_ is now known as morcos
7272017-12-11T21:56:27 *** Lightsword_ is now known as Lightsword
7282017-12-11T21:56:33 <jtimon> I kind of missed that whole discussion
7292017-12-11T21:56:56 *** mr_burdell is now known as Guest97470
7302017-12-11T21:57:09 *** d9b4bef9 has joined #bitcoin-core-dev
7312017-12-11T21:59:16 *** eck has joined #bitcoin-core-dev
7322017-12-11T21:59:26 *** GAit has joined #bitcoin-core-dev
7332017-12-11T22:02:39 *** promag has joined #bitcoin-core-dev
7342017-12-11T22:02:46 <jb55> sipa: wouldn't it stay in the mempool if it keeps rebroadcasting it? here's my logs https://jb55.com/s/42dd917b1b1b4b05.txt
7352017-12-11T22:03:55 <jb55> I guess I'll just double spend it
7362017-12-11T22:10:20 <jb55> would be nice if there was some way to tell my node to stop broadcasting it, I though that's what abandon would do but I can't abandon because it keeps getting rebroadcasted and stays in my local mempool! Unless I'm confused about something.
7372017-12-11T22:10:27 *** dermoth has quit IRC
7382017-12-11T22:10:55 *** dermoth has joined #bitcoin-core-dev
7392017-12-11T22:15:12 *** promag has quit IRC
7402017-12-11T22:15:41 *** Guyver2 has quit IRC
7412017-12-11T22:16:36 <sipa> jb55: ah, yes agree wth that
7422017-12-11T22:19:21 <sipa> not quite abandoning, but at least stoo broadcasting
7432017-12-11T22:21:52 *** Cogito_Ergo_Sum has quit IRC
7442017-12-11T22:22:42 *** intcat has quit IRC
7452017-12-11T22:23:16 *** rfdavid_ has joined #bitcoin-core-dev
7462017-12-11T22:29:44 *** Lauda_ is now known as Lauda
7472017-12-11T22:30:38 *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
7482017-12-11T22:31:15 *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
7492017-12-11T22:31:15 *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
7502017-12-11T22:33:26 *** dermoth has quit IRC
7512017-12-11T22:34:59 *** dermoth has joined #bitcoin-core-dev
7522017-12-11T22:41:24 *** StopAndDecrypt has joined #bitcoin-core-dev
7532017-12-11T22:41:25 *** StopAndDecrypt has quit IRC
7542017-12-11T22:41:25 *** StopAndDecrypt has joined #bitcoin-core-dev
7552017-12-11T22:42:42 *** _biO_ has quit IRC
7562017-12-11T22:42:59 *** Victor_sueca has quit IRC
7572017-12-11T22:44:23 *** Victor_sueca has joined #bitcoin-core-dev
7582017-12-11T22:57:18 *** saint_ has quit IRC
7592017-12-11T23:01:10 *** leofoto123 has joined #bitcoin-core-dev
7602017-12-11T23:05:05 *** cheese_ has quit IRC
7612017-12-11T23:06:04 <gmaxwell> I agree that stop broadcasting would be reasonable, however I also don't think it'll be very useful: the recieving side will also rebroadcast, and so will random nodes on the network
7622017-12-11T23:06:50 *** Cogito_Ergo_Sum has quit IRC
7632017-12-11T23:06:50 <gmaxwell> probably when we add a "I've seen this in a mempool before" flag on wtx we should add a "I should keep trying to rebroadcast" and have abort set that to false.
7642017-12-11T23:19:40 *** HarlequinFields has joined #bitcoin-core-dev
7652017-12-11T23:23:44 *** tomdickharry has joined #bitcoin-core-dev
7662017-12-11T23:23:47 <tomdickharry> https://bitcointalk.org/index.php?topic=2569202.0
7672017-12-11T23:23:56 <tomdickharry> https://bitcointalk.org/index.php?topic=2569202.0
7682017-12-11T23:26:17 *** Dizzle has quit IRC
7692017-12-11T23:27:40 *** dermoth has quit IRC
7702017-12-11T23:29:25 *** meshcollider has joined #bitcoin-core-dev
7712017-12-11T23:34:27 *** promag has joined #bitcoin-core-dev
7722017-12-11T23:36:33 *** pkx2 has quit IRC
7732017-12-11T23:38:35 <jb55> gmaxwell: well the case I was referring to was specifically ResendWalletTransactions, which only applys to transactions in your own node. It didn't stop rebroadcasting (for a month) until I passed in walletbroadcast=0 which seems a bit overkill
7742017-12-11T23:39:16 *** go1111111 has joined #bitcoin-core-dev
7752017-12-11T23:39:36 *** dermoth has joined #bitcoin-core-dev
7762017-12-11T23:44:22 <gmaxwell> jb55: I know, my point was that even if _you_ stop, the reciever will keep going, as will random people on the network who rebroadcast other people's transactions for unclear reasons.
7772017-12-11T23:44:45 <gmaxwell> I think it's reasonable to have a way to stop, but at the same time don't expect it to be very useful.
7782017-12-11T23:45:40 *** promag has quit IRC
7792017-12-11T23:55:42 *** crazyprodigy has quit IRC
7802017-12-11T23:55:42 *** stevenroose has quit IRC
7812017-12-11T23:56:50 *** midnightmagic has quit IRC
7822017-12-11T23:56:51 *** schnerchi has quit IRC
7832017-12-11T23:57:13 *** mturquette has quit IRC
7842017-12-11T23:57:14 *** mariorz has quit IRC
7852017-12-11T23:57:14 *** ibrightly has quit IRC
7862017-12-11T23:57:14 *** TheV01d has quit IRC
7872017-12-11T23:57:37 *** xHire has quit IRC
7882017-12-11T23:58:44 *** xHire has joined #bitcoin-core-dev
7892017-12-11T23:59:23 *** mturquette has joined #bitcoin-core-dev
7902017-12-11T23:59:47 *** mariorz has joined #bitcoin-core-dev