--- Day changed Mon Dec 11 2017
00:02 < warren> Does anyone use gitian with qemu-kvm instead of lxc?
00:03 < warren> MarcoFalke: have you tested your gitian instructions on Fedora 27?  both with qemu-kvm and lxc?
00:03 < warren> Does anyone using gitian with qemu-kvm particularly on Ubuntu or Debian?
00:04 < Randolf> warren:  You might also ask in the #qemu channel, just in case someone there can be helpful too.  :)
00:04 < warren> Randolf: no, this is very gitian and bitcoin specific
00:04 < Randolf> Oh, okay.
00:04 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
00:05 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
00:05 < Randolf> I was merely thinking of a potentially wider audience.  :)
00:05 < 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
00:05 < Randolf> Cool!
00:05 < Randolf> Having more than one way to do things is always a plus.
00:05 < warren> Randolf: the way we qemu or lxc is very different from what most other people are familiar with
00:06 < 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.
00:07 < Randolf> ...and also qemu-kvm.
00:08 < warren> qemu-kvm is just hardware accelerated qemu
00:08 < warren> using kvm as a hypervisor, I think is the terminology
00:10 < 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.
00:10 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
00:11 < 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.
00:11 < warren> So curious if MarcoFalke tested the qemu method of gitian
00:12 < warren> My packaged python-vm-builder is different than the "pip" method he uses to install it from Ubuntu
00:12 < Randolf> Does qcow (as opposed to qcow2) also exhibit the same problematic behaviour?
00:12 -!- blackbaba [~blackbaba@gateway/vpn/privateinternetaccess/blackbaba] has quit [Quit: Going offline, see ya! (www.adiirc.com)]     
00:13 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
00:13 < warren> I don't think that's the issue. It's something installed or configured in the image file when it is generated.
00:13 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Ping timeout: 248 seconds]     
00:14 < Randolf> Oh.     
00:15 < warren> gitian qemu-kvm works just fine if I copy that base image from an Ubuntu machine
00:15 < Randolf> (Thanks for the link, by the way.  I've opened it and will read it soon.)
00:15 < warren> something is wrong with that tool on Fedora, it worked in Fedora 24 last i know
00:18 < warren> I suspect it's grub2 or something not installing in the image file 
00:20 < TD-Linux> have you tried both efi and bios boot with qemu?
00:20 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
00:21 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
00:29 < warren> it's something in the image file ... 
00:29 < warren> image copied from Ubuntu works fine
00:30 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
00:30 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
00:34 -!- CubicEarth [~cubiceart@xdsl-31-164-85-6.adslplus.ch] has joined #bitcoin-core-dev     
00:38 -!- laurentmt [~Thunderbi@92.154.68.134] has joined #bitcoin-core-dev     
00:48 -!- JackH [~laptop@91.189.61.70] has joined #bitcoin-core-dev     
01:01 -!- go1111111 [~go1111111@gateway/vpn/privateinternetaccess/go1111111] has joined #bitcoin-core-dev     
01:06 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 276 seconds]     
01:09 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
01:10 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
01:11 -!- tattoovicious [~tattoovic@78.90.9.207] has joined #bitcoin-core-dev     
01:12 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
01:13 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
01:17 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
01:19 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev     
01:19 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 268 seconds]     
01:39 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev     
01:49 -!- CubicEarth [~cubiceart@xdsl-31-164-85-6.adslplus.ch] has quit [Remote host closed the connection]     
01:51 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection]     
02:01 -!- pkx2 [~pkx@unaffiliated/pkx] has joined #bitcoin-core-dev     
02:02 -!- pkx2 [~pkx@unaffiliated/pkx] has quit [Remote host closed the connection]     
02:05 -!- CubicEarth [~cubiceart@xdsl-31-164-85-6.adslplus.ch] has joined #bitcoin-core-dev     
02:12 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 248 seconds]     
02:13 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev     
02:14 -!- tattoovicious [~tattoovic@78.90.9.207] has quit [Quit: Leaving]     
02:17 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
02:18 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
02:21 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
02:23 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
02:24 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
02:24 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
02:24 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev     
02:25 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
02:27 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
02:33 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection]     
02:42 -!- CubicEarth [~cubiceart@xdsl-31-164-85-6.adslplus.ch] has quit [Remote host closed the connection]     
02:42 -!- CubicEarth [~cubiceart@xdsl-31-164-85-6.adslplus.ch] has joined #bitcoin-core-dev     
02:55 -!- Kozuch [~Kozuch@81.0.198.168] has joined #bitcoin-core-dev     
03:00 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev     
03:23 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has quit [Ping timeout: 248 seconds]     
03:25 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
03:30 -!- cluelessperson [~cluelessp@unaffiliated/cluelessperson] has quit [Quit: Laters]     
03:30 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
03:31 -!- cluelessperson [~cluelessp@unaffiliated/cluelessperson] has joined #bitcoin-core-dev     
03:31 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
03:32 -!- cluelessperson [~cluelessp@unaffiliated/cluelessperson] has quit [Client Quit]     
03:33 -!- cluelessperson [~cluelessp@unaffiliated/cluelessperson] has joined #bitcoin-core-dev     
03:43 -!- cluelessperson [~cluelessp@unaffiliated/cluelessperson] has quit [Quit: Laters]     
03:44 -!- cluelessperson [~cluelessp@unaffiliated/cluelessperson] has joined #bitcoin-core-dev     
04:00 -!- FakeSatoshiLite [~quassel@c-24-130-219-18.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
04:06 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
04:10 -!- zombieC [~zombieC@ua-85-227-38-68.cust.bredbandsbolaget.se] has joined #bitcoin-core-dev     
04:11 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection]     
04:12 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev     
04:12 -!- FakeSatoshiLite [~quassel@c-24-130-219-18.hsd1.ca.comcast.net] has quit [Remote host closed the connection]     
04:15 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]     
04:25 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev     
04:26 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
04:27 -!- cluelessperson [~cluelessp@unaffiliated/cluelessperson] has quit [Quit: Laters]     
04:28 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
04:29 -!- cluelessperson [~cluelessp@unaffiliated/cluelessperson] has joined #bitcoin-core-dev     
04:34 -!- cheese_ [~Cheeseo@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
04:38 -!- cluelessperson [~cluelessp@unaffiliated/cluelessperson] has quit [Quit: Laters]     
04:39 -!- Danilo_ [~quassel@179.97.233.74] has joined #bitcoin-core-dev     
04:39 -!- Danilo_ is now known as danguafer     
04:41 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
04:42 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
04:43 -!- cluelessperson [~cluelessp@unaffiliated/cluelessperson] has joined #bitcoin-core-dev     
04:46 -!- cyber55 [~cyber55@unaffiliated/cyber55] has quit [Read error: Connection reset by peer]     
04:56 < Provoostenator> mryandao: there may be some useful hints here too: https://gist.github.com/Sjors/70f14baf1f834f3547bf35553faff610
04:58 -!- AdilibA [295c21ad@gateway/web/freenode/ip.41.92.33.173] has joined #bitcoin-core-dev     
04:58 < AdilibA> Hi     
04:59 -!- CubicEarth [~cubiceart@xdsl-31-164-85-6.adslplus.ch] has quit [Remote host closed the connection]     
05:00 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev     
05:00 < AdilibA> i want to share a scalling solution that i was thinking about it lately
05:00 < AdilibA> Is anyone there?
05:02 -!- Danilo_ [~quassel@179.97.233.74] has joined #bitcoin-core-dev     
05:03 < AdilibA> The solution i was thinking about is by adding compression work in addition to minning work
05:04 -!- danguafer [~quassel@179.97.233.74] has quit [Ping timeout: 255 seconds]     
05:04 < AdilibA> Add the compression limit is the block size
05:05 -!- Danilo__ [~quassel@179.97.233.74] has joined #bitcoin-core-dev     
05:06 -!- Danilo_ [~quassel@179.97.233.74] has quit [Ping timeout: 240 seconds]     
05:07 -!- Thora1Koelpin [~Thora1Koe@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
05:08 < 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.
05:09 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection]     
05:09 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
05:15 -!- AdilibA [295c21ad@gateway/web/freenode/ip.41.92.33.173] has quit [Ping timeout: 260 seconds]     
05:18 -!- cheese_ [~Cheeseo@unaffiliated/cheeseo] has quit [Ping timeout: 248 seconds]     
05:20 < 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).
05:21 -!- JackH [~laptop@91.189.61.70] has quit [Ping timeout: 240 seconds]     
05:21 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev     
05:22 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
05:23 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 248 seconds]     
05:24 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
05:25 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
05:28 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
05:29 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev     
05:29 -!- Cogito_Ergo_Sum [~Myself@ppp-94-64-159-176.home.otenet.gr] has joined #bitcoin-core-dev     
05:29 -!- Cogito_Ergo_Sum [~Myself@ppp-94-64-159-176.home.otenet.gr] has quit [Changing host]     
05:29 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has joined #bitcoin-core-dev     
05:36 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
05:36 -!- pkx2 [~pkx@unaffiliated/pkx] has joined #bitcoin-core-dev     
05:44 -!- AdilebA [295c6b92@gateway/web/freenode/ip.41.92.107.146] has joined #bitcoin-core-dev     
05:45 -!- AdilebA [295c6b92@gateway/web/freenode/ip.41.92.107.146] has quit [Client Quit]     
06:00 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
06:00 -!- Danilo__ [~quassel@179.97.233.74] has quit [Remote host closed the connection]     
06:01 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
06:05 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
06:06 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
06:07 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
06:08 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
06:10 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
06:11 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
06:14 < 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
06:15 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
06:18 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has quit [Ping timeout: 248 seconds]     
06:23 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
06:24 -!- hoge_ [~hoge@ngn9-ppp85.tokyo.sannet.ne.jp] has joined #bitcoin-core-dev     
06:24 -!- hoge_ [~hoge@ngn9-ppp85.tokyo.sannet.ne.jp] has quit [Client Quit]     
06:26 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Ping timeout: 240 seconds]     
06:33 -!- promag [~promag@89.214.85.17] has joined #bitcoin-core-dev     
06:40 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
06:43 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 240 seconds]     
06:43 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
06:45 -!- Emcy_ [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 250 seconds]     
06:48 -!- alcipir [~user@187.102.146.50] has joined #bitcoin-core-dev     
06:48 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 268 seconds]     
06:49 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
06:52 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]     
06:56 < BlueMatt> phantomcircuit: promise? you mean std::promise, or the shared_ptr to the block?
06:57 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-zsywvksnwvpcsitc] has quit [Quit: Connection closed for inactivity]     
06:59 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
07:06 -!- indistylo [~indistylo@119.82.105.106] has quit [Ping timeout: 240 seconds]     
07:07 -!- HarlequinFields [~Harlequin@c-69-137-88-131.hsd1.tn.comcast.net] has joined #bitcoin-core-dev     
07:17 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
07:19 < 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
07:19 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
07:21 < bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/f60b4ad57912...8ab6c0b09e4e
07:21 < bitcoin-git> bitcoin/master 6ba8f30 Gregory Sanders: don't attempt mempool entry for wallet transactions on startup if already in mempool
07:21 < bitcoin-git> bitcoin/master 6697a70 Gregory Sanders: add test for unconfirmed balance between restarts
07:21 < bitcoin-git> bitcoin/master 8ab6c0b Wladimir J. van der Laan: Merge #11839: don't attempt mempool entry for wallet transactions on startup if alr…...
07:22 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
07:23 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
07:26 -!- newbie-- [~irc@mirk.info] has joined #bitcoin-core-dev     
07:26 -!- alcipir [~user@187.102.146.50] has quit [Quit: ERC (IRC client for Emacs 25.1.1)]     
07:39 -!- drizztbsd [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
07:40 -!- timothy [~tredaelli@redhat/timothy] has quit [Ping timeout: 246 seconds]     
07:43 -!- Mattie-161 is now known as Mattie161     
07:43 -!- BGL [sixty@75-149-171-58-Washington.hfc.comcastbusiness.net] has quit [Read error: Connection reset by peer]     
07:45 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
07:48 -!- promag [~promag@89.214.85.17] has quit [Remote host closed the connection]     
07:49 -!- dcousens [~dcousens@CPE-101-181-85-60.lnse5.cha.bigpond.net.au] has quit [Ping timeout: 268 seconds]     
07:50 -!- dcousens [~dcousens@CPE-101-181-97-230.lnse5.cha.bigpond.net.au] has joined #bitcoin-core-dev     
07:56 -!- Jair [3b7d4879@gateway/web/freenode/ip.59.125.72.121] has joined #bitcoin-core-dev     
07:56 -!- Jair [3b7d4879@gateway/web/freenode/ip.59.125.72.121] has quit [Client Quit]     
07:57 -!- alcipir [~user@187.102.146.50] has joined #bitcoin-core-dev     
08:05 -!- alcipir [~user@187.102.146.50] has quit [Ping timeout: 246 seconds]     
08:07 -!- DvdKhl [~Arokh@ip-37-201-210-118.hsi13.unitymediagroup.de] has joined #bitcoin-core-dev     
08:09 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
08:11 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
08:11 -!- MarcoFalke [~none@198.12.116.246] has quit [Ping timeout: 240 seconds]     
08:12 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
08:12 -!- MarcoFalke [~none@198.12.116.246] has joined #bitcoin-core-dev     
08:22 -!- CubicEarth [~cubiceart@xdsl-31-164-85-6.adslplus.ch] has joined #bitcoin-core-dev     
08:23 -!- emzy [~quassel@unaffiliated/emzy] has quit [Quit: No Ping reply in 180 seconds.]     
08:24 -!- emzy [~quassel@raspberry.emzy.de] has joined #bitcoin-core-dev     
08:27 < 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
08:30 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]     
08:30 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev     
08:30 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
08:31 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
08:41 -!- Kozuch [~Kozuch@81.0.198.168] has quit [Ping timeout: 260 seconds]     
08:44 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]     
08:44 -!- BGL [fourty@75-149-171-58-Washington.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
08:44 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev     
08:50 -!- alcipir [~user@187.102.146.50] has joined #bitcoin-core-dev     
08:55 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]     
08:55 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev     
09:04 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
09:05 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
09:05 < cluelessperson> I have a serious question.  What are thoughts on seperating the Bitcoin Core wallet and Bitcoin Core node?
09:06 < 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.
09:07 < 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
09:08 < wumpus> isn't there a PR that adds SPV functionality to the wallet?
09:08 < wumpus> I don't think bringing this up as a discussion topic yet again is productiv
09:08 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ejhknpyneytenodx] has joined #bitcoin-core-dev     
09:08 < wumpus> it's been discussed zillions of times since 2012 or so
09:09 < wumpus> every time the conclusion was that yes, it's desirable, if you want it, work toward it
09:09 < 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
09:09 < wumpus> feel free to work on it
09:09 < cluelessperson> I'll do what I can.
09:09 < cluelessperson> my skill sets are limited, I'm sorry
09:09 < cluelessperson> I ask for broader shoulders
09:09 < wumpus> #10794 is jonasschnelli's PR in that direction
09:09 < gribble> https://github.com/bitcoin/bitcoin/issues/10794 | Add simple light-client mode (RPC only) by jonasschnelli · Pull Request #10794 · bitcoin/bitcoin · GitHub
09:12 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
09:14 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
09:15 -!- jb55 [~jb55@208.98.200.100] has joined #bitcoin-core-dev     
09:26 -!- DvdKhl [~Arokh@ip-37-201-210-118.hsi13.unitymediagroup.de] has quit [Ping timeout: 240 seconds]     
09:27 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]     
09:28 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
09:29 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]     
09:29 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev     
09:33 < Provoostenator> cluelessperson: as for multiple wallets: #10740 and #11383
09:33 < gribble> https://github.com/bitcoin/bitcoin/issues/10740 | [wallet] dynamic loading/unloading of wallets by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
09:33 < gribble> https://github.com/bitcoin/bitcoin/issues/11383 | Basic Multiwallet GUI support by luke-jr · Pull Request #11383 · bitcoin/bitcoin · GitHub
09:34 < Provoostenator> There's several pull requests that make small steps in this direction, mostly just improving the code quality and separating stuff better.
09:35 < cluelessperson> Provoostenator: unfortunately, I'm not a coding expert, and I don't know C++.  I have no power here.
09:35 < cluelessperson> I wish I could actually help
09:36 < cluelessperson> I'm stuck with documentation and community support. DEVOPs and the like
09:36 -!- indistylo [~indistylo@171.48.28.254] has joined #bitcoin-core-dev     
09:36 < Provoostenator> Well, both can be learned.
09:36 < Provoostenator> And these other contributions also help, as they take work off the shoulders of developers.
09:37 < 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 :-)
09:38 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has quit [Read error: Connection reset by peer]     
09:39 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #bitcoin-core-dev     
09:41 -!- drizztbsd [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]     
09:45 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
09:59 < cluelessperson> Provoostenator: I'm trying but I have no path forward
09:59 < cluelessperson> I'm taking college classes, but not sure where this is leading honestly
10:00 < alcipir> How long does it take for a seasoned web developer to get into C++? 
10:02 < 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.
10:03 < alcipir> Hm, I've been doing object-oriented PHP for years now, although I don't like it as a language
10:03 < alcipir> also know a bit of Java and C#
10:03 < alcipir> but C++ seems pretty daunting at first, seems like it changes a lot over time
10:04 < 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.  :)
10:05 < 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.
10:05 < alcipir> I see, thanks for the tip :) 
10:05 < Randolf> You're welcome.
10:09 -!- lrvick [~weechat_u@ec2-52-27-169-212.us-west-2.compute.amazonaws.com] has quit [Ping timeout: 250 seconds]     
10:10 -!- HarlequinFields [~Harlequin@c-69-137-88-131.hsd1.tn.comcast.net] has quit [Ping timeout: 268 seconds]     
10:10 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
10:10 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev     
10:11 -!- paveljanik [~paveljani@79.98.72.176] has joined #bitcoin-core-dev     
10:11 -!- paveljanik [~paveljani@79.98.72.176] has quit [Changing host]     
10:11 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev     
10:11 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
10:13 < 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
10:14 < sipa> i think the discussion is getting a bit offtopic
10:16 -!- mrfrasha [~mrfrasha@66-188-250-34.dhcp.eucl.wi.charter.com] has joined #bitcoin-core-dev     
10:17 -!- jamesob [~james@199.230.10.198] has joined #bitcoin-core-dev     
10:18 < alcipir> thanks Provoostenator, and sorry for the offtopic discussion
10:22 -!- lrvick [~weechat_u@ec2-52-27-169-212.us-west-2.compute.amazonaws.com] has joined #bitcoin-core-dev     
10:24 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
10:26 < michagogo> Why do we still have a "Pay only the required fee of 1 satoshi/byte" checkbox?
10:26 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
10:27 < 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
10:28 < 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
10:28 -!- mrfrasha [~mrfrasha@66-188-250-34.dhcp.eucl.wi.charter.com] has quit [Quit: mrfrasha]     
10:34 -!- mrfrasha [~mrfrasha@66-188-250-34.dhcp.eucl.wi.charter.com] has joined #bitcoin-core-dev     
10:37 -!- Szadek [~Szadek@2001:ac8:28:15::5e] has joined #bitcoin-core-dev     
10:37 < wumpus> I don't know, feel free to file a PR to remove it and see if there's interest / pushback
10:38 < 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
10:40 -!- laurentmt [~Thunderbi@92.154.68.134] has quit [Quit: laurentmt]     
10:43 -!- CubicEarth [~cubiceart@xdsl-31-164-85-6.adslplus.ch] has quit [Ping timeout: 260 seconds]     
10:47 -!- quantbot [~quantbot@38.101.106.141] has joined #bitcoin-core-dev     
10:55 -!- emzy [~quassel@raspberry.emzy.de] has quit [Changing host]     
10:55 -!- emzy [~quassel@unaffiliated/emzy] has joined #bitcoin-core-dev     
10:58 -!- jtimon [~quassel@164.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
11:00 -!- JackH [~laptop@abnd35.neoplus.adsl.tpnet.pl] has joined #bitcoin-core-dev     
11:00 -!- CubicEarth [~cubiceart@xdsl-31-164-85-6.adslplus.ch] has joined #bitcoin-core-dev     
11:05 < gmaxwell> Bluematt: re: transaction delayed bundles:
11:05 < 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 
11:05 < 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 
11:05 < gmaxwell> a small loss.
11:05 < 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. 
11:05 < gmaxwell> BlueMatt: I don't think there is a reason to make the standard rpcs do this,  just add new ones:  "bundlesend" (works 
11:05 < gmaxwell> like sendmany, but takes a maximum waittime argument) "bundleabort" (can cancel a transaction using a handle returned 
11:05 < gmaxwell> by bundlesend) "bundleforce" (forces the current bundle to send now) or something... and a behavior that sends N 
11:05 < gmaxwell> seconds after the last addition, or when the first timeout is hit.
11:05 < gmaxwell> unless it would really be a burden to change the rpc calls their software is making... but I think thats unavoidable 
11:06 < gmaxwell> since you can't return a txid.
11:06 < gmaxwell> For a while I've wanted a standardized signed payment confirmation code, basically a signature with some well known key
11:06 < gmaxwell> that says "I promise to pay X btc to address Y", which would be a potential candidate for what gets returned, but
11:06 < gmaxwell> perhaps too much scope creep.
11:06 < 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.
11:06 < BlueMatt> yes, thats probably scope creep
11:07 < BlueMatt> but, generally, I think these could be added quite simply to large benefit of some users
11:07 < 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.
11:08 < jonasschnelli> wumpus: https://github.com/bitcoin/bitcoin/pull/11845
11:08 < 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
11:08 < jonasschnelli> The key links to btcplt.org (Bitcoin Platinum)
11:08 < BlueMatt> gmaxwell: yea, that really sucks, dunno how to get away from it except for rbf, sadly
11:08 < gmaxwell> BlueMatt: with the signed code I just suggested.
11:08 < 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
11:08 < jonasschnelli> Not sure if we want a key leading to the Bitcoin Platinum project in our repository,... could be missued for advertising?
11:08 < BlueMatt> gmaxwell: yes, but block explorers wont support that for...20 years
11:09 < gmaxwell> BlueMatt: meh, bc.i had sorta support for bech32 addresses when segwit activated.
11:09 < gmaxwell> some kind of signmessage thing wouldn't be a big deal to support, doesn't require a blockchain to back it.
11:09 < BlueMatt> gmaxwell: I'm super skeptical, but would love to be proven wrong....
11:09 < BlueMatt> true, could signmessage magic
11:09 < gmaxwell> I mean, any of us could also put up little dumb js pages for that.
11:10 < 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)
11:10 < 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.
11:10 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
11:10 < 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?)
11:10 < jonasschnelli> Provoostenator: no... I don't think so...
11:11 < jonasschnelli> Provoostenator: there is always an email (or pretty much always) attached...
11:11 < 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
11:11 < 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.
11:11 < Provoostenator> Nvm, you can't see the email in a .asc file either; just need to import it to see.
11:11 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
11:11 < BlueMatt> yes     
11:11 -!- HarlequinFields [~Harlequin@c-69-137-88-131.hsd1.tn.comcast.net] has joined #bitcoin-core-dev     
11:12 -!- HarlequinFields [~Harlequin@c-69-137-88-131.hsd1.tn.comcast.net] has quit [Client Quit]     
11:12 -!- HarlequinFields [~Harlequin@c-69-137-88-131.hsd1.tn.comcast.net] has joined #bitcoin-core-dev     
11:12 < gmaxwell> BlueMatt: batch interface's spec should be "will get a payment made of the specified amounts to the specified addresses accomplished eventually"
11:12 < 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?)
11:12 < gmaxwell> well I think they've never thought of these things, so we'd have to propose them.
11:13 < BlueMatt> yes, thats my point :p
11:13 -!- woozyn [25e4f0a7@gateway/web/freenode/ip.37.228.240.167] has joined #bitcoin-core-dev     
11:14 -!- CubicEarth [~cubiceart@xdsl-31-164-85-6.adslplus.ch] has quit [Ping timeout: 240 seconds]     
11:16 < 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.
11:18 < BlueMatt> well bundletx verbose=X
11:18 < gmaxwell> rpcs that return all txn like listtransactions kinda stink.
11:18 < BlueMatt> i mean get the tx for the bundle in raw (or hex, or txid) form
11:19 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
11:19 < gmaxwell> ah.     
11:19 < sipa> is there a need to support multiple bundles simultaneously?
11:19 < BlueMatt> little reason not to, but probably not?
11:19 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
11:20 < sipa> my thinking was that there'd just be a single set of output/amount pairs that are in flight
11:20 < sipa> and any time you update it, a new transaction is created
11:21 < sipa> which is guaranteed to conflict with earlier transactions
11:21 < BlueMatt> you mean and not announce them?
11:21 < gmaxwell> the guarenteed to conflict will result in suboptimal coin selection.
11:21 < BlueMatt> rbf would have to be optional given receiving rbf txn right now sucks
11:21 < sipa> gmaxwell: sure
11:21 < gmaxwell> BlueMatt: I described above creating the tx at RPC not announce time.
11:21 < adiabat> related to pre-signing a bunch of txs with increasing fee rates, what if you have incremental locktimes on them?
11:22 < gmaxwell> sipa: why bother with a guarentee to conflict, if you give the user no access to the txn itself until announce time?
11:22 < 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?
11:22 -!- Scooooobydooo [68b59ecd@gateway/web/freenode/ip.104.181.158.205] has joined #bitcoin-core-dev     
11:22 < adiabat> would it then be possible to have nodes relay the txs even if they're not-yet-minable?
11:22 < sipa> gmaxwell: well it would need to conflict at least with broadcasted transactions
11:22 < gmaxwell> adiabat: setting locktimes on precreated replacements is the obvious thing to do, suggested every time it has come up.
11:23 < adiabat> gmaxwell: ok what's the catch...?
11:23 < gmaxwell> adiabat: relaying a non-mingable transaction is an immediate and nasty DOS vector... what value do you see in that?
11:23 < BlueMatt> some people dont want to do rbf cause the client-side wallets may handle it like garbage
11:23 < sipa> gmaxwell: in my earlier descriptions of this idea there was no separation between creation of the transaction and broadcastng
11:23 < gmaxwell> adiabat: there is no catch, if bitcoin core ever does replacement fully I assume it'll presign with locktimes.
11:24 < sipa> but it does make sense - you may want to perform multiple updates frequently, but only occasionally issue a new transaction
11:24 < adiabat> gmaxwell: value is that wallets can fire-and-forget; DoS is the issue but feels like it could be managed
11:24 < 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.
11:24 < BlueMatt> Provoostenator: agreed, but also a chicken-and-egg issue there
11:24 -!- CubicEarth [~cubiceart@xdsl-31-164-85-6.adslplus.ch] has joined #bitcoin-core-dev     
11:25 < gmaxwell> adiabat: best of luck with that.
11:25 < 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?
11:25 < adiabat> gmaxwell: heh :)  Yeah it's hard to not get banned
11:25 < BlueMatt> (hell, even with rbf you have lots of annoying corner-cases)
11:25 < sipa> BlueMatt: of course it would RBF
11:25 < BlueMatt> sipa: the whole point was to make rbf optional..........
11:26 < sipa> maybe we're talking about something unrelated then :)
11:26 < BlueMatt> see discussion above...
11:26 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]     
11:26 < BlueMatt> a tx bundle api would have to have rbf be optional
11:26 < sipa> meh     
11:26 < gmaxwell> sipa: the point of this discussion was to enable parties to sendmany.
11:26 < 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
11:26 < gmaxwell> Right now too many people use txid as an effective unique key for a payment.. you utterly break stuff by rbfing.
11:26 < BlueMatt> sipa: feel free to go help user-level wallets fix their rbf-receive ux
11:27 < sipa> fair
11:27 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
11:27 < BlueMatt> rbf appears to work pretty sell *sending* to services, but a service sending rbf to a user-side wallet....bad ux
11:27 < 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
11:27 -!- Szadek [~Szadek@2001:ac8:28:15::5e] has quit [Quit: ---.--....---.-----.--....----]     
11:28 < BlueMatt> no, I'm talking about building an api now...not something no one will use
11:28 < sipa> okay, ignore e
11:28 < 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?
11:28 < BlueMatt> adiabat: doesnt ln have like a model where folks run servers which auto-broadcast in the future? just piggy back on them
11:28 < BlueMatt> no need to relay it in bitcoin p2p net?
11:29 < adiabat> yup, asking because I'm working on similar stuff
11:29 < adiabat> Hmm... OK so maybe code LN stuff to accept not-yet-OK RBF txs instead?
11:29 < sipa> accepting things into your mempool which can't confirm soon undermines its DoS protection
11:30 < 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)
11:30 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 255 seconds]     
11:30 < 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
11:30 < sipa> as we rely on assuming that everything in the mempool will eventually be either confirmed or replaced with something paying a higher fee
11:30 < BlueMatt> then its a generic service
11:30 < adiabat> right, for small N might be doable if nodes opt-in
11:30 < 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"
11:30 < 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?
11:31 < 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
11:31 < adiabat> gmaxwell: I agree; I'm mainly thinking about the logistics of different nodes / codebases
11:31 < 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. 
11:32 < adiabat> easy enough to have a website which says "give your future-dated RBF txs" and has a captcha or something
11:32 < BlueMatt> or add it to ln nodes? dont they have some ability to do similar things?
11:33 < BlueMatt> might as well let them do it for any txn with payment of 5 satoshis over ln or so?
11:33 < adiabat> right now LN nodes don't have actual tx storage for other nodes
11:33 < adiabat> but it's something that could be added
11:33 < adiabat> I have been looking at bumping fees for funding channels and it's a little tricky due to multisig / multiple parties
11:34 -!- dcousens [~dcousens@CPE-101-181-97-230.lnse5.cha.bigpond.net.au] has quit [Ping timeout: 246 seconds]     
11:35 -!- dcousens [~dcousens@CPE-101-181-44-212.lnse4.cha.bigpond.net.au] has joined #bitcoin-core-dev     
11:35 < 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?
11:35 < gribble> https://github.com/bitcoin/bitcoin/issues/11605 | [Wallet] Enable RBF by default in QT by Sjors · Pull Request #11605 · bitcoin/bitcoin · GitHub
11:35 < Provoostenator> (every ATM that uses the Core wallet)
11:35 < gmaxwell> Provoostenator: hm? there is no problem signaling RBF if you don't make use of it.
11:36 < gmaxwell> The problems arise when you make use of it.
11:36 < 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?
11:36 < BlueMatt> yea, ok, that too, if you dont use it it doesnt matter
11:36 < gmaxwell> The issue for the batching thing is that if it used RBF it would immeidately make use of it.
11:36 < Provoostenator> Ok, that's a good point. Wallets indeed suck even more at that.
11:36 < Provoostenator> They complain it's a double spend, might even mess up the balance.
11:36 < 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.
11:37 < 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
11:37 < gmaxwell> but still, flagging rbf is pretty much harmless, I believe electrum does this by default already without incident...
11:37 -!- quantbot_ [~quantbot@38.101.106.141] has joined #bitcoin-core-dev     
11:38 < gmaxwell> BlueMatt: I dunno, if anything current RBF restrictions are too lax because mempool minfee is unrealistically low.
11:39 < BlueMatt> yea, well possibly minfee needs to be higher with the incremental/relay fee lower for rbf? dunno, worth exploring
11:39 -!- dcousens [~dcousens@CPE-101-181-44-212.lnse4.cha.bigpond.net.au] has quit [Ping timeout: 250 seconds]     
11:40 < 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.   
11:40 -!- dcousens [~dcousens@CPE-101-181-44-212.lnse4.cha.bigpond.net.au] has joined #bitcoin-core-dev     
11:41 < Provoostenator> Like I make a tx with a €0.50 fee and it says the minimum for a fee bump is €25.
11:41 -!- quantbot [~quantbot@38.101.106.141] has quit [Ping timeout: 255 seconds]     
11:41 < BlueMatt> that....doesnt sound right
11:41 < BlueMatt> oh, yea, greenaddress' feebump is really annoying
11:41 < gmaxwell> for greenaddress IIRC it only currently supports one bump, so it only offers it at whatever the shortest fee estimate is.
11:41 < 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.
11:41 -!- quantbot_ [~quantbot@38.101.106.141] has quit [Ping timeout: 248 seconds]     
11:41 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
11:42 < BlueMatt> gmaxwell: no, it offers several, but they're all relatively short
11:42 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
11:43 < Provoostenator> https://twitter.com/Provoost/status/925245638379483137
11:43 < gmaxwell> Provoostenator: the bumpfee in bitcoin core however lets you set whatever target you want AFAIR.
11:44 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev     
11:44 < 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.
11:44 < Provoostenator> (and enforcing the correct minimum, etc)
11:44 < gmaxwell> you might want to also do something to handle the minim..right
11:44 < adiabat> bitcoin-qt bump fee only gives you one option though; cli lets you set whatever you want
11:44 < gmaxwell> I'd forgotten we had anything in the GUI yet.
11:45 < adiabat> you can right click on txs and there's an "increase fee" option
11:45 < Provoostenator> I'm trying to Make QT Great Again :-) 
11:45 < gmaxwell> it's still relatively useless due to not being able to change the input set.
11:45 < adiabat> brings up a modal with OK / cancel
11:47 < 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?
11:48 < 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.
11:50 < gmaxwell> uhg. no... the correct thing to do is to just drop the same-inputs restriction.
11:51 < gmaxwell> it was just done that way to make it faster to implement, but it's a bad restriction.
11:51 < Provoostenator> That does sound cleaner. Is that restriction part of the BIP?
11:51 < gmaxwell> absolutely not
11:51 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 255 seconds]     
11:51 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has quit [Ping timeout: 248 seconds]     
11:52 < Provoostenator> Ok, so the first step there would be to change bumpfee RPC to let go of same-input?
11:52 -!- StopAndDecrypt [~StopAndDe@c-73-248-248-9.hsd1.nj.comcast.net] has joined #bitcoin-core-dev     
11:52 -!- StopAndDecrypt [~StopAndDe@c-73-248-248-9.hsd1.nj.comcast.net] has quit [Changing host]     
11:52 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #bitcoin-core-dev     
11:52 -!- DvdKhl [~Arokh@ip-37-201-210-118.hsi13.unitymediagroup.de] has joined #bitcoin-core-dev     
11:52 < Provoostenator> But somehow track what you've used, because I assuem there has to be overlap in inputs.
11:52 < Provoostenator> (between all versions)
11:53 < gmaxwell> Probably easiest to let it add additional inputs, this requires plumbing through mandatory inputs to the coin selection logic.
11:53 < gmaxwell> technically they merely needs to be an overlap. But it's simpler to superset and I think hardly worse.
11:53 < gmaxwell> Supersetting is better for privacy.
11:54 -!- helo [~helo@unaffiliated/helo] has quit [Ping timeout: 240 seconds]     
11:55 -!- helo [~helo@unaffiliated/helo] has joined #bitcoin-core-dev     
11:56 < Provoostenator> And the wallet keeps all previous versions around and knows which ones they are? (doesn't matter in the superset case)
11:57 -!- booyah [~bb@193.25.1.157] has quit [Read error: Connection reset by peer]     
11:57 < gmaxwell> Thats why the superset case is easier to implement.
11:57 < Provoostenator> Supersetting in combination with my idea above of overshooting the initial selection?
11:58 < Provoostenator> (though that can always be done later)
11:59 < gmaxwell> there is no reason to overshoot the initial.
11:59 < gmaxwell> we should be trying to avoid producing dusty change (e.g. change in value comparible to fees)
12:00 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]     
12:00 -!- MarcoFalke [~none@198.12.116.246] has quit [Ping timeout: 276 seconds]     
12:00 < 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.
12:01 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Quit: Leaving]     
12:02 < gmaxwell> well you'll pay the fees for that extra input eventually, so it's not that bad to add it. 
12:02 < gmaxwell> the cost of the extra input is just the difference in the feerate between now and when you might use it later.
12:02 -!- MarcoFalke [~none@198.12.116.246] has joined #bitcoin-core-dev     
12:09 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev     
12:09 -!- woozyn [25e4f0a7@gateway/web/freenode/ip.37.228.240.167] has quit [Ping timeout: 260 seconds]     
12:11 < luke-jr> gmaxwell: but you need to cover the cost of the data/weight for the first tx as well?
12:11 < luke-jr> not sure it matters much in practice I guess
12:13 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
12:15 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
12:16 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
12:17 < Provoostenator> Probably not when fees are at a level where you actually need RBF.
12:17 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
12:17 < Provoostenator> At what point would you expect most node operators to increase the minimum relay fee?
12:18 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev     
12:23 < gmaxwell> Provoostenator: we don't expect anyone to increase the minimum relay fee, we expect it to increase automatically.
12:23 < gmaxwell> unfortunately it's not, seemingly because the mempool is too big.
12:25 < 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) ?
12:26 < sipa> the first is controlled by the mempool limiting; the second is just a configurable constant
12:26 < sipa> (luke-jr was talking about the second)
12:31 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
12:32 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
12:40 < morcos> gmaxwell: it got quite high before the weekend, i think 40 sat/B
12:42 < morcos> is there any reason that resendwallettransactions needs to be a hidden RPC only used for testing?
12:42 < morcos> doesn't it seem kind of useful to be able to fully create and locally accept transactions, but not broadcast them until ready
12:42 < morcos> is it just a privacy concern?
12:43 < morcos> this is partly in response to the ongoing discussion in #10247 right now
12:43 < gribble> https://github.com/bitcoin/bitcoin/issues/10247 | cost too many fees? · Issue #10247 · bitcoin/bitcoin · GitHub
12:43 < gmaxwell> you mean turn off wallet broadcast and trigger broadcasting yourself?
12:44 < morcos> yeah exactly
12:44 < 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.
12:44 < gmaxwell> but I think it's fine, personally I always run with broadcasting off.
12:45 < instagibbs> do you just sendraw when ready?
12:45 < morcos> ah, i suppose sendraw accomplish what i wanted to suggest pretty well
12:47 < phantomcircuit> personally i disable internet when i want to do that...
12:48 -!- cheese_ [~Cheeseo@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
12:50 -!- Kozuch [~Kozuch@81.0.198.168] has joined #bitcoin-core-dev     
13:07  * luke-jr wonders why the GUI is blocked until rescan finishes
13:07 -!- _biO_ [~biO_@ip-84-119-230-91.unity-media.net] has joined #bitcoin-core-dev     
13:10 -!- alcipir [~user@187.102.146.50] has quit [Ping timeout: 268 seconds]     
13:11 -!- indistylo [~indistylo@171.48.28.254] has quit [Ping timeout: 240 seconds]     
13:11 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
13:12 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
13:13 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
13:13 -!- booyah [~bb@193.25.1.157] has joined #bitcoin-core-dev     
13:15 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
13:16 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
13:18 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
13:25 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has quit [Ping timeout: 246 seconds]     
13:26 -!- StopAndDecrypt [~StopAndDe@c-73-248-248-9.hsd1.nj.comcast.net] has joined #bitcoin-core-dev     
13:26 -!- StopAndDecrypt [~StopAndDe@c-73-248-248-9.hsd1.nj.comcast.net] has quit [Changing host]     
13:26 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #bitcoin-core-dev     
13:27 -!- go1111111 [~go1111111@gateway/vpn/privateinternetaccess/go1111111] has quit [Quit: Leaving]     
13:28 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
13:30 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has quit [Ping timeout: 240 seconds]     
13:30 -!- StopAndDecrypt [~StopAndDe@c-73-248-248-9.hsd1.nj.comcast.net] has joined #bitcoin-core-dev     
13:30 -!- StopAndDecrypt [~StopAndDe@c-73-248-248-9.hsd1.nj.comcast.net] has quit [Changing host]     
13:30 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #bitcoin-core-dev     
13:31 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
13:33 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
13:34 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
13:35 -!- atroxes [~atroxes@unaffiliated/atroxes] has quit [Quit: bye]     
13:36 -!- atroxes [~atroxes@unaffiliated/atroxes] has joined #bitcoin-core-dev     
13:42 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Remote host closed the connection]     
13:43 -!- ekrok [~ekrok@85.200.34.95.customer.cdi.no] has quit [Ping timeout: 246 seconds]     
13:43 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev     
13:47 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
13:47 -!- Kozuch_ [~Kozuch@81.0.198.168] has joined #bitcoin-core-dev     
13:47 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has quit [Ping timeout: 240 seconds]     
13:48 -!- _parts_ [~tonedef@104.236.96.151] has joined #bitcoin-core-dev     
13:48 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
13:49 -!- [\\\] [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev     
13:50 -!- ekrok [~ekrok@85.200.34.95.customer.cdi.no] has joined #bitcoin-core-dev     
13:50 < 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? 
13:51 -!- Scooooobydooo [68b59ecd@gateway/web/freenode/ip.104.181.158.205] has quit [Quit: Page closed]     
13:51 -!- eenoch_ [~eenoch@unaffiliated/eenoch] has joined #bitcoin-core-dev     
13:51 -!- Lauda_ [~quassel@unaffiliated/lauda] has joined #bitcoin-core-dev     
13:51 -!- wump [~quassel@pdpc/supporter/professional/wumpus] has joined #bitcoin-core-dev     
13:51 -!- c40d9b0753a91f40 [~2c232c25c@unaffiliated/c40d9b0743a91f40] has joined #bitcoin-core-dev     
13:52 -!- scoooobydooo [68b59ecd@gateway/web/freenode/ip.104.181.158.205] has joined #bitcoin-core-dev     
13:52 -!- mr_burdell_ [~mr_burdel@bounce.cryptolabs.net] has joined #bitcoin-core-dev     
13:52 < 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
13:53 < sipa> you could try to double-spend the transaction, but it may not get relayed by other nodes, for example
13:53 < jb55> I've just had a tx that's been around for a month and it looks like my node keeps rebroadcasting it?
13:55 -!- molz [~IRCIdent@unaffiliated/molly] has joined #bitcoin-core-dev     
13:55 -!- Lightsword_ [~Lightswor@2604:a880:1:20::1d3:9001] has joined #bitcoin-core-dev     
13:55 -!- morcos_ [~morcos@158.1.155.104.bc.googleusercontent.com] has joined #bitcoin-core-dev     
13:56 -!- achow101_ [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev     
13:56 < jtimon> MarcoFalke: what needs to be done for https://github.com/bitcoin/bitcoin/pull/8994/commits/52f6f43968595a769b109b9b6987ab03275c4a9d#r153922809 ?
13:56 -!- mr_burdell_ is now known as mr_burdell     
13:56 -!- morcos_ is now known as morcos     
13:56 -!- Lightsword_ is now known as Lightsword     
13:56 < jtimon> I kind of missed that whole discussion
13:56 -!- mr_burdell is now known as Guest97470     
13:57 -!- Netsplit over, joins: d9b4bef9
13:59 -!- Netsplit over, joins: GAit, eck
14:02 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
14:02 < jb55> sipa: wouldn't it stay in the mempool if it keeps rebroadcasting it? here's my logs https://jb55.com/s/42dd917b1b1b4b05.txt
14:03 < jb55> I guess I'll just double spend it
14:10 < 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.
14:10 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Remote host closed the connection]     
14:10 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev     
14:15 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
14:15 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]     
14:16 < sipa> jb55: ah, yes agree wth that
14:19 < sipa> not quite abandoning, but at least stoo broadcasting
14:21 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has quit [Ping timeout: 240 seconds]     
14:22 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
14:23 -!- rfdavid_ [~rfdavid@ip-45-3-15-253.user.start.ca] has joined #bitcoin-core-dev     
14:29 -!- Lauda_ is now known as Lauda     
14:30 -!- Cogito_Ergo_Sum [~Myself@80.107.151.135] has joined #bitcoin-core-dev     
14:30 -!- Cogito_Ergo_Sum [~Myself@80.107.151.135] has quit [Client Quit]     
14:31 -!- Cogito_Ergo_Sum [~Myself@80.107.151.135] has joined #bitcoin-core-dev     
14:31 -!- Cogito_Ergo_Sum [~Myself@80.107.151.135] has quit [Changing host]     
14:31 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has joined #bitcoin-core-dev     
14:33 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Remote host closed the connection]     
14:34 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev     
14:41 -!- StopAndDecrypt [~StopAndDe@c-73-248-248-9.hsd1.nj.comcast.net] has joined #bitcoin-core-dev     
14:41 -!- StopAndDecrypt [~StopAndDe@c-73-248-248-9.hsd1.nj.comcast.net] has quit [Changing host]     
14:41 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #bitcoin-core-dev     
14:42 -!- _biO_ [~biO_@ip-84-119-230-91.unity-media.net] has quit [Remote host closed the connection]     
14:42 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
14:44 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
14:57 -!- saint_ [~saint_@unaffiliated/saint-/x-0540772] has quit [Quit: UNIVERSE CORRUPTED. REBOOT (Y/N) ?]     
15:01 -!- leofoto123 [b897b247@gateway/web/freenode/ip.184.151.178.71] has joined #bitcoin-core-dev     
15:05 -!- cheese_ [~Cheeseo@unaffiliated/cheeseo] has quit [Ping timeout: 240 seconds]     
15:06 < 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
15:06 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has quit []     
15:06 < 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.
15:19 -!- HarlequinFields [~Harlequin@c-68-52-70-169.hsd1.tn.comcast.net] has joined #bitcoin-core-dev     
15:23 -!- tomdickharry [~dom@109.76.174.127] has joined #bitcoin-core-dev     
15:23 < tomdickharry> https://bitcointalk.org/index.php?topic=2569202.0
15:23 < tomdickharry> https://bitcointalk.org/index.php?topic=2569202.0
15:26 -!- Dizzle [~dizzle@108.171.182.16] has quit [Quit: Leaving...]     
15:27 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Ping timeout: 248 seconds]     
15:29 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-hqeyrpkwbzljzvns] has joined #bitcoin-core-dev     
15:34 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
15:36 -!- pkx2 [~pkx@unaffiliated/pkx] has quit [Remote host closed the connection]     
15:38 < 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
15:39 -!- go1111111 [~go1111111@gateway/vpn/privateinternetaccess/go1111111] has joined #bitcoin-core-dev     
15:39 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev     
15:44 < 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.
15:44 < 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.
15:45 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
15:55 -!- crazyprodigy [sid194503@gateway/web/irccloud.com/x-yhnqtiwsybgpuecs] has quit [Ping timeout: 258 seconds]     
15:55 -!- stevenroose [~steven@vps.weuste.club] has quit [Ping timeout: 258 seconds]     
15:56 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 258 seconds]     
15:56 -!- schnerchi [~schnerchi@2a01:4f8:c0c:afe::2] has quit [Ping timeout: 258 seconds]     
15:57 -!- mturquette [sid66043@gateway/web/irccloud.com/x-kqzfrhpqkrtjiggv] has quit [Ping timeout: 258 seconds]     
15:57 -!- mariorz [sid490@gateway/web/irccloud.com/x-fllzvoucpxikwvbr] has quit [Ping timeout: 258 seconds]     
15:57 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-esbfixqqpnjuovzr] has quit [Ping timeout: 258 seconds]     
15:57 -!- TheV01d [thev01d@btc.mining.ga] has quit [Ping timeout: 258 seconds]     
15:57 -!- xHire [~xHire@kos.paskuli.cz] has quit [Ping timeout: 258 seconds]     
15:58 -!- xHire [~xHire@kos.paskuli.cz] has joined #bitcoin-core-dev     
15:59 -!- mturquette [sid66043@gateway/web/irccloud.com/x-tgedrohzntedshwt] has joined #bitcoin-core-dev     
15:59 -!- mariorz [sid490@gateway/web/irccloud.com/x-mducobohizeoajni] has joined #bitcoin-core-dev     
16:00 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-pplqfyntkefbzyso] has joined #bitcoin-core-dev     
16:02 -!- TheV01d [thev01d@btc.mining.ga] has joined #bitcoin-core-dev     
16:02 -!- stevenroose [~steven@vps.weuste.club] has joined #bitcoin-core-dev     
16:03 -!- schnerchi [~schnerchi@2a01:4f8:c0c:afe::2] has joined #bitcoin-core-dev     
16:03 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
16:03 -!- cyber55 [~cyber55@unaffiliated/cyber55] has joined #bitcoin-core-dev     
16:06 -!- Emcy_ [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 260 seconds]     
16:10 -!- crazyprodigy [sid194503@gateway/web/irccloud.com/x-bsouflqlbxyweoks] has joined #bitcoin-core-dev     
16:11 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-core-dev     
16:14 -!- shtirlic [~shtirlic@ec2-35-158-173-101.eu-central-1.compute.amazonaws.com] has quit [Quit: ZNC - http://znc.in]     
16:15 -!- shtirlic [~shtirlic@ec2-35-158-173-101.eu-central-1.compute.amazonaws.com] has joined #bitcoin-core-dev     
16:17 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]     
16:17 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
16:19 -!- sipa [~pw@unaffiliated/sipa1024] has quit [Ping timeout: 255 seconds]     
16:24 -!- mrfrasha [~mrfrasha@66-188-250-34.dhcp.eucl.wi.charter.com] has quit [Quit: mrfrasha]     
16:24 -!- HarlequinFields [~Harlequin@c-68-52-70-169.hsd1.tn.comcast.net] has quit [Ping timeout: 268 seconds]     
16:27 -!- pierre_rochard [~pierre_ro@unaffiliated/pierre-rochard/x-3593157] has joined #bitcoin-core-dev     
16:29 -!- HarlequinFields [~Harlequin@c-68-52-70-169.hsd1.tn.comcast.net] has joined #bitcoin-core-dev     
16:29 < pierre_rochard> Does each wallet in vpwallets have a unique identifier? 
16:32 -!- achow101_ is now known as achow101     
16:34 -!- sipa [~pw@2001:19f0:ac01:2fb:5400:ff:fe5b:c3ff] has joined #bitcoin-core-dev     
16:44 -!- jamesob [~james@199.230.10.198] has quit [Ping timeout: 240 seconds]     
16:50 -!- leofoto123 [b897b247@gateway/web/freenode/ip.184.151.178.71] has quit [Ping timeout: 260 seconds]     
16:55 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
16:56 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
16:56 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev     
16:59 -!- newbold_ [~adam@23.95.228.154] has quit [Ping timeout: 240 seconds]     
17:01 -!- vchengsong [67d64440@gateway/web/freenode/ip.103.214.68.64] has joined #bitcoin-core-dev     
17:02 -!- jb55 [~jb55@208.98.200.100] has quit [Ping timeout: 260 seconds]     
17:05 -!- DrFeelGood [~DrFeelGoo@unaffiliated/olufunmilayo] has joined #bitcoin-core-dev     
17:18 -!- zombieC [~zombieC@ua-85-227-38-68.cust.bredbandsbolaget.se] has quit [Ping timeout: 248 seconds]     
17:19 -!- HarlequinFields [~Harlequin@c-68-52-70-169.hsd1.tn.comcast.net] has quit [Ping timeout: 268 seconds]     
17:29 -!- Kozuch_ [~Kozuch@81.0.198.168] has quit [Ping timeout: 248 seconds]     
17:29 -!- bule [~bule@gateway/tor-sasl/bule] has joined #bitcoin-core-dev     
17:31 -!- vchengsong [67d64440@gateway/web/freenode/ip.103.214.68.64] has quit [Quit: Page closed]     
17:33 -!- DvdKhl [~Arokh@ip-37-201-210-118.hsi13.unitymediagroup.de] has quit [Ping timeout: 246 seconds]     
17:44 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ejhknpyneytenodx] has quit [Quit: Connection closed for inactivity]     
17:45 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]     
17:46 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev     
17:48 -!- HarlequinFields [~Harlequin@c-69-137-88-131.hsd1.tn.comcast.net] has joined #bitcoin-core-dev     
18:01 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has quit [Quit: leaving]     
18:03 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
18:03 -!- tomdickharry [~dom@109.76.174.127] has quit [Ping timeout: 260 seconds]     
18:05 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
18:15 -!- Roberto_2000 [~colin@2605:6000:cdc9:3b00:9dd0:5973:fc80:a578] has joined #bitcoin-core-dev     
18:20 -!- dongcarl [~dongcarl@169.229.22.214] has joined #bitcoin-core-dev     
18:27 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
18:35 -!- toorx [46bbac04@gateway/web/freenode/ip.70.187.172.4] has joined #bitcoin-core-dev     
18:47 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Remote host closed the connection]     
18:47 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev     
18:48 < kallewoof> I had no idea nodes randomly rebroadcasted other people's transactions. Double spending is the only solution then. (Another case for RBF default on)
18:48 < sipa> kallewoof: some sites do
18:49 < sipa> though in general, nodes don't
18:49 < sipa> there is nothing to prevent them to, though
18:49 < sipa> and i think we'd be better off if there was some mempool synchronization that levelled the field
18:49 < kallewoof> Just see no reason for them to do it.
18:50 < kallewoof> Mempool synchronization? Like what?
18:51 < phantomcircuit> sipa, there are nodes that rebroadcast transactions seemingly on a timer
18:52 < gmaxwell> kallewoof: bitcoin core doesn't rebroadcast third party txn, but random bozos do, because they think they're helping in some cases, or because they want to pump up mempool stats. or god knows why
18:52 < phantomcircuit> either way, transactions do not expire
18:52 < gmaxwell> mempool sync is discussed some here: https://bitcointalk.org/index.php?topic=1377345.0
18:54 < kallewoof> gmaxwell: Ohh, okay. Thanks! (I should be on bitcointalk more often I guess)
19:03 -!- dongcarl [~dongcarl@169.229.22.214] has quit [Ping timeout: 240 seconds]     
19:04 < phantomcircuit> kallewoof, i'd generally advise against that unless you filter for pre 2014
19:10 -!- tomdickharry [~dom@109.79.185.230] has joined #bitcoin-core-dev     
19:18 -!- CubicEarth [~cubiceart@xdsl-31-164-85-6.adslplus.ch] has quit [Remote host closed the connection]     
19:19 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-hqeyrpkwbzljzvns] has quit [Quit: Connection closed for inactivity]     
19:19 < kallewoof> phantomcircuit: I very rarely visit it, but it seems like it has a lot of in-depth discussion.
19:21 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
19:21 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has joined #bitcoin-core-dev     
19:22 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
19:43 -!- dongcarl [~dongcarl@169.229.22.214] has joined #bitcoin-core-dev     
19:43 -!- dongcarl [~dongcarl@169.229.22.214] has left #bitcoin-core-dev []     
19:46 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-xiskuywgahcravif] has joined #bitcoin-core-dev     
19:47 < meshcollider> kallewoof: so much rubbish too though unfortunately
19:52 -!- toorx [46bbac04@gateway/web/freenode/ip.70.187.172.4] has quit [Ping timeout: 260 seconds]     
19:53 -!- Issues2 [~Issues4@d24-150-128-151.home.cgocable.net] has joined #bitcoin-core-dev     
19:54 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
19:54 -!- Issues2 [~Issues4@d24-150-128-151.home.cgocable.net] has left #bitcoin-core-dev []     
19:56 -!- HarlequinFields [~Harlequin@c-69-137-88-131.hsd1.tn.comcast.net] has quit [Ping timeout: 246 seconds]     
20:01 -!- roadcrap [~roadcrypt@unaffiliated/roadcrap] has quit [Remote host closed the connection]     
20:03 -!- cheetah2 [~cheetah2@45.74.95.97] has joined #bitcoin-core-dev     
20:04 -!- cheetah2 [~cheetah2@45.74.95.97] has quit [Client Quit]     
20:11 < kallewoof> meshcollider: That's unfortunate.
20:38 < sipa> kallewoof: i think i stopped frequenting bitcointalk in 2012 maybe
20:38 < sipa> or 2013
20:39 < gmaxwell> it's no worse than the mailing list now.
20:39 < gmaxwell> actually, I think it's better. There are a lot of dull and repetative posts on both, but BCT more promptly gets replies directing people to the last 20 times the material was discussed.
20:42 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
20:43 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
20:59 < kallewoof> Heh     
21:09 -!- HarlequinFields [~Harlequin@c-69-137-88-131.hsd1.tn.comcast.net] has joined #bitcoin-core-dev     
21:17 -!- mrfrasha [~mrfrasha@66-188-250-34.dhcp.eucl.wi.charter.com] has joined #bitcoin-core-dev     
21:18 -!- StopAndDecrypt_ [~StopAndDe@c-73-248-248-9.hsd1.nj.comcast.net] has joined #bitcoin-core-dev     
21:19 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has quit [Ping timeout: 246 seconds]     
21:24 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
21:24 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 248 seconds]     
21:25 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev     
21:28 -!- michagogo [uid14316@wikia/Michagogo] has quit [Ping timeout: 258 seconds]     
21:29 -!- michagogo [uid14316@wikia/Michagogo] has joined #bitcoin-core-dev     
21:30 -!- lnostdal [~lnostdal@62.90-149-73.nextgentel.com] has joined #bitcoin-core-dev     
21:31 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has quit [Quit: Snoozing.]     
21:40 -!- commavir [vir@2604:180::502b:135a] has quit [Ping timeout: 258 seconds]     
21:41 -!- commavir [vir@2604:180::502b:135a] has joined #bitcoin-core-dev     
21:42 -!- roadcrap [~roadcrypt@unaffiliated/roadcrap] has joined #bitcoin-core-dev     
21:43 -!- knight_ [7ab40bca@gateway/web/freenode/ip.122.180.11.202] has joined #bitcoin-core-dev     
21:44 -!- cheese_ [~Cheeseo@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
21:47 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]     
21:47 -!- knight_ [7ab40bca@gateway/web/freenode/ip.122.180.11.202] has quit [Ping timeout: 260 seconds]     
21:48 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
21:48 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev     
21:48 -!- cheese_ [~Cheeseo@unaffiliated/cheeseo] has quit [Ping timeout: 240 seconds]     
21:48 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has quit [Client Quit]     
21:52 -!- imabinarydigit01 [~IRCTestSS@52.179.96.28] has quit [Remote host closed the connection]     
21:53 -!- imabinarydigit01 [~IRCTestSS@52.179.96.28] has joined #bitcoin-core-dev     
21:53 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
21:54 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
21:54 -!- quantbot [~quantbot@ool-2f125d98.dyn.optonline.net] has joined #bitcoin-core-dev     
21:59 -!- quantbot [~quantbot@ool-2f125d98.dyn.optonline.net] has quit [Ping timeout: 260 seconds]     
22:01 -!- imabinarydigit01 [~IRCTestSS@52.179.96.28] has quit [Remote host closed the connection]     
22:01 -!- imabinarydigit01 [~IRCTestSS@52.179.96.28] has joined #bitcoin-core-dev     
22:02 -!- Toxo [18ca14a9@gateway/web/freenode/ip.24.202.20.169] has joined #bitcoin-core-dev     
22:21 -!- alfa [uid11513@gateway/web/irccloud.com/x-aslvwbhrfjbwxejq] has joined #bitcoin-core-dev     
22:26 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]     
22:26 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
22:28 -!- indistylo [~indistylo@119.82.105.106] has joined #bitcoin-core-dev     
22:28 -!- indistylo [~indistylo@119.82.105.106] has quit [Max SendQ exceeded]     
22:29 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-xiskuywgahcravif] has quit [Quit: Connection closed for inactivity]     
22:30 -!- Kernelstack [42448d8a@gateway/web/freenode/ip.66.68.141.138] has joined #bitcoin-core-dev     
22:31 -!- Kernelstack [42448d8a@gateway/web/freenode/ip.66.68.141.138] has quit [Client Quit]     
22:32 -!- mrfrasha [~mrfrasha@66-188-250-34.dhcp.eucl.wi.charter.com] has quit [Quit: mrfrasha]     
22:34 -!- bule [~bule@gateway/tor-sasl/bule] has quit [Remote host closed the connection]     
22:46 -!- Toxo [18ca14a9@gateway/web/freenode/ip.24.202.20.169] has quit [Ping timeout: 260 seconds]     
22:50 -!- jtimon [~quassel@164.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds]     
22:50 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-mmkgvyeirbahyear] has joined #bitcoin-core-dev     
22:56 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
22:57 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 248 seconds]     
23:03 -!- Roberto_2000 [~colin@2605:6000:cdc9:3b00:9dd0:5973:fc80:a578] has quit [Quit: Leaving]     
23:09 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-aybklnhucttguaky] has joined #bitcoin-core-dev     
23:15 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 246 seconds]     
23:15 -!- DvdKhl [~Arokh@ip-37-201-210-118.hsi13.unitymediagroup.de] has joined #bitcoin-core-dev     
23:17 -!- HarlequinFields [~Harlequin@c-69-137-88-131.hsd1.tn.comcast.net] has quit []     
23:17 -!- Cogito_Ergo_Sum [~Myself@80.107.151.135] has joined #bitcoin-core-dev     
23:17 -!- Cogito_Ergo_Sum [~Myself@80.107.151.135] has quit [Changing host]     
23:17 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has joined #bitcoin-core-dev     
23:20 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
23:21 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
23:24 -!- Victor_sueca is now known as Victorsueca     
23:26 < Provoostenator> sipa: so both the minimum fee required to get in the mempool and to bump transactions are both set by minrelayfee, but because there's also an MB limit to the mempool per node, that determines the effective minimum for the former?
23:28 < sipa> Provoostenator: run getmempoolinfo
23:29 < sipa> if your mempool is full, it will report a nonzero minrelayfee
23:30 < sipa> any time a transaction is kicked out of the mempool, the new relay fee is raised to the fee of what was kicked out
23:30 < sipa> and then it decays slowly back to 0
23:30 < Provoostenator> Ok, so it's more than an emergent property from the fact that low fees are kicked out.
23:34 < sipa> the goal is to have it carefully actually track the lowest acceptable feerate for your mempool
23:34 < sipa> which doesn't work if the mempool is always empty ;)
23:35 < Provoostenator> If people change their mempool size to something not standard, doesn't that create a fingerprinting opportunity? 
23:36 < sipa> yup     
23:37 < sipa> nodes even communicate their approximate minimum feerate to each other
23:45 -!- Sillent [~sillent@static-dsl-208.87-197-105.telecom.sk] has quit [Quit: Leaving]     
23:55 < Provoostenator> sipa: I'm doing a fresh make clean and make now to see if I can reproduce the test error. I did that yesterday as well, but I wonder how reproducable it is.
23:56 < sipa> Provoostenator: also wipe your test cache
23:56 < sipa> (test/cache directory)
23:56 < Provoostenator> Ah, why doesn't make clean do that?
23:56 < sipa> because make clean removes the results of make
23:56 < sipa> the test cache isn't produced by make
23:57 < Provoostenator> make nuke?
23:57 < sipa> PR's welcome :p
23:58 < Provoostenator> I can try. Do have an objection to make clean doing this? Or should it be another command? I can't see why anyone would possibly want to keep the test cache around after running make clean. 
23:59 < sipa> cfields: opinions? ^