--- Day changed Mon Dec 21 2015 00:11 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev 00:20 -!- JackH [~Jack@host-80-43-141-42.as13285.net] has joined #bitcoin-core-dev 00:21 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 00:38 -!- p15_ [~p15@40.91.145.64.client.static.strong-tk2.bringover.net] has quit [Max SendQ exceeded] 00:39 -!- p15 [~p15@4.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-core-dev 00:41 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:44 -!- BashCo_ [BashCo@gateway/vpn/mullvad/x-amhzukboiyaozzkv] has joined #bitcoin-core-dev 00:44 -!- phantomcircuit [~phantomci@strateman.ninja] has quit [Max SendQ exceeded] 00:45 -!- phantomcircuit [~phantomci@strateman.ninja] has joined #bitcoin-core-dev 00:46 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 245 seconds] 00:57 -!- phantomcircuit [~phantomci@strateman.ninja] has left #bitcoin-core-dev [] 01:08 -!- go1111111 [go1111111@174-20-190-87.mpls.qwest.net] has quit [] 01:08 -!- wangchun [~wangchun@li414-193.members.linode.com] has quit [Quit: leaving] 01:09 -!- wangchun [~wangchun@li414-193.members.linode.com] has joined #bitcoin-core-dev 01:16 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 260 seconds] 01:18 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Ping timeout: 240 seconds] 01:18 -!- xiangfu [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev 01:43 -!- Taek42 [~quassel@2001:41d0:1:472e::] has joined #bitcoin-core-dev 01:44 -!- p15 [~p15@4.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 255 seconds] 01:45 -!- crescend1 [~mozart@173.203.100.20] has joined #bitcoin-core-dev 01:45 -!- neha_ [~narula@mint-square.mit.edu] has joined #bitcoin-core-dev 01:45 -!- Eliel_ [~jojkaart@jkaartinen.iki.fi] has joined #bitcoin-core-dev 01:48 -!- da2ce7_mobile_ [~da2ce7@opentransactions/dev/da2ce7] has joined #bitcoin-core-dev 01:49 -!- p15 [~p15@119.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-core-dev 01:49 -!- Netsplit *.net <-> *.split quits: nkuttler, Eliel, da2ce7_mobile, teward, neha, Taek, crescendo 01:52 -!- Netsplit over, joins: teward 01:54 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev 01:57 -!- instagibbs_ [~instagibb@pool-100-15-134-80.washdc.fios.verizon.net] has joined #bitcoin-core-dev 01:58 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Ping timeout: 264 seconds] 02:03 -!- sdaftuar_ [~sdaftuar@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 02:06 -!- bsm1175321 [~mcelrath@static-108-21-236-13.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 02:06 -!- berndj-blackout [~berndj@azna.co.za] has joined #bitcoin-core-dev 02:06 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Disconnected by services] 02:10 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev 02:11 -!- zxzzt_ [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 02:12 -!- Netsplit *.net <-> *.split quits: zxzzt, Yoghur114, berndj, sdaftuar, instagibbs, bsm117532 02:16 -!- Netsplit over, joins: Yoghur114 02:21 -!- Tera2342 [~Tera2342@171.5.153.152] has quit [Ping timeout: 244 seconds] 02:24 -!- Amnez777 [~Amnez777@37.157.216.149] has quit [Ping timeout: 272 seconds] 02:26 -!- Amnez777 [~Amnez777@37.157.216.149] has joined #bitcoin-core-dev 02:30 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 264 seconds] 02:48 -!- Tera2342 [~Tera2342@171.5.153.152] has joined #bitcoin-core-dev 03:19 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev 03:23 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 03:23 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 03:29 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer] 03:29 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 03:43 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 03:52 -!- p15 [~p15@119.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 246 seconds] 03:55 -!- MarcoFalke [8af6023d@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.61] has joined #bitcoin-core-dev 04:01 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.] 04:18 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Remote host closed the connection] 04:36 -!- Tera2342 [~Tera2342@171.5.153.152] has quit [Ping timeout: 260 seconds] 04:39 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev 04:46 -!- MarcoFalke [8af6023d@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.61] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 05:11 -!- laurentmt1 [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev 05:12 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Ping timeout: 276 seconds] 05:12 -!- laurentmt1 is now known as laurentmt 05:12 -!- MarcoFalke [8af6023d@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.61] has joined #bitcoin-core-dev 05:31 -!- MarcoFalke [8af6023d@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.61] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 05:31 -!- MarcoFalke [8af6023d@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.61] has joined #bitcoin-core-dev 06:07 -!- MarcoFalke [8af6023d@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.61] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 06:13 -!- Tera2342 [~Tera2342@171.5.153.152] has joined #bitcoin-core-dev 06:19 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev 06:42 -!- Greyboy [~meat@unaffiliated/greyboy] has joined #bitcoin-core-dev 06:53 -!- Tera2342 [~Tera2342@171.5.153.152] has quit [Ping timeout: 245 seconds] 06:53 -!- dipk [~d1pk@50.248.81.65] has quit [Quit: Leaving] 07:08 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev 07:10 -!- instagibbs_ is now known as instagibbs 07:32 -!- zookolaptop [~user@c-73-217-96-13.hsd1.co.comcast.net] has joined #bitcoin-core-dev 07:36 -!- zookolap` [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-core-dev 07:37 -!- zookolap` is now known as zooko 07:38 -!- zookolaptop [~user@c-73-217-96-13.hsd1.co.comcast.net] has quit [Ping timeout: 265 seconds] 07:38 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 245 seconds] 08:03 -!- brg444 [18257df2@gateway/web/freenode/ip.24.37.125.242] has joined #bitcoin-core-dev 08:14 < GitHub78> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/8ea5ef1d3994...c24337964f2d 08:14 < GitHub78> bitcoin/master eb30666 Suhas Daftuar: Fix mempool limiting for PrioritiseTransaction... 08:14 < GitHub78> bitcoin/master 9ef2a25 Suhas Daftuar: Update replace-by-fee logic to use fee deltas 08:14 < GitHub78> bitcoin/master 27fae34 Suhas Daftuar: Use fee deltas for determining mempool acceptance 08:14 < GitHub80> [bitcoin] laanwj closed pull request #7062: [Mempool] Fix mempool limiting and replace-by-fee for PrioritiseTransaction (master...fix-mempool-limiting) https://github.com/bitcoin/bitcoin/pull/7062 08:20 < GitHub74> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/12c469b236aa9b31b3744e5c529b9236dda27b27 08:20 < GitHub74> bitcoin/0.12 12c469b Suhas Daftuar: [Mempool] Fix mempool limiting and replace-by-fee for PrioritiseTransaction... 08:23 -!- BashCo_ [BashCo@gateway/vpn/mullvad/x-amhzukboiyaozzkv] has quit [Remote host closed the connection] 08:35 -!- Thireus1 [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev 08:35 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Remote host closed the connection] 08:40 < morcos> wumpus: sigh... that's sad, but the right move. it was a needed fix, so if there are problems with it, we'll fix those too 08:40 < morcos> (7062) 08:56 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 08:57 -!- BashCo_ [BashCo@gateway/vpn/mullvad/x-rbntkhcyxajbivpw] has joined #bitcoin-core-dev 09:00 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 255 seconds] 09:11 -!- alpalp [~alp@104-54-235-28.lightspeed.austtx.sbcglobal.net] has quit [Remote host closed the connection] 09:14 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-core-dev 09:14 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has quit [Changing host] 09:14 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 09:51 -!- Thireus1 [~Thireus@icy.thireus.fr] has quit [Remote host closed the connection] 10:03 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 10:03 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Max SendQ exceeded] 10:04 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 10:04 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 240 seconds] 10:19 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt] 10:39 -!- berndj-blackout is now known as berndj 10:56 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 11:02 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev 11:04 -!- JackH [~Jack@host-80-43-141-42.as13285.net] has quit [Ping timeout: 240 seconds] 11:05 -!- Yoghur114_2 [~jorn@g227014.upc-g.chello.nl] has joined #bitcoin-core-dev 11:06 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev 11:07 -!- JackH [~Jack@host-80-43-141-42.as13285.net] has joined #bitcoin-core-dev 11:08 -!- jcorgan|away is now known as jcorgan 11:08 -!- Quent1 is now known as Quent 11:11 < cfields> Luke-Jr: i said you'd have to export it yourself :) 11:13 < GitHub179> [bitcoin] bom64 opened pull request #7242: 0.12 Change the -keypool info text (master...0.12) https://github.com/bitcoin/bitcoin/pull/7242 11:21 -!- zookolaptop [~user@2601:281:8001:26aa:f823:7965:aaca:8589] has joined #bitcoin-core-dev 11:30 -!- jtimon [~quassel@74.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 245 seconds] 11:41 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 260 seconds] 11:45 < GitHub71> [bitcoin] jrmithdobbs opened pull request #7243: This community NEEDS to adopt a code of conduct. Recent events make t… (master...code_of_conduct) https://github.com/bitcoin/bitcoin/pull/7243 12:24 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 12:26 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 276 seconds] 12:28 -!- brg444 [18257df2@gateway/web/freenode/ip.24.37.125.242] has quit [Quit: Page closed] 12:46 -!- proslogion [~proslogio@2.221.238.82] has joined #bitcoin-core-dev 12:47 -!- proslogion [~proslogio@2.221.238.82] has left #bitcoin-core-dev [] 12:47 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 260 seconds] 12:48 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev 12:52 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 265 seconds] 12:54 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev 13:25 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Read error: Connection reset by peer] 13:25 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev 13:38 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 13:39 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Quit: Leaving] 13:41 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev 13:58 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Quit: Leaving.] 13:58 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev 14:08 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev 14:11 -!- jcorgan is now known as jcorgan|away 14:16 -!- JackH [~Jack@host-80-43-141-42.as13285.net] has quit [Ping timeout: 260 seconds] 14:20 -!- raedah [~raedah@172.56.38.251] has quit [Quit: Leaving] 14:22 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev 14:23 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit] 14:28 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection] 14:31 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev 14:34 -!- Taek42 is now known as Taek 14:49 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] 14:53 -!- brg444 [46346d00@gateway/web/freenode/ip.70.52.109.0] has joined #bitcoin-core-dev 14:58 -!- Prattler [~ttttt@78-60-12-33.static.zebra.lt] has joined #bitcoin-core-dev 15:02 -!- raedah [~raedah@mf40536d0.tmodns.net] has joined #bitcoin-core-dev 15:07 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has quit [Ping timeout: 255 seconds] 15:08 -!- desantis [~desantis@68.66.103.249] has joined #bitcoin-core-dev 15:15 -!- raedah [~raedah@mf40536d0.tmodns.net] has quit [Ping timeout: 264 seconds] 15:20 -!- raedah [~raedah@mf40536d0.tmodns.net] has joined #bitcoin-core-dev 15:24 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 15:26 -!- phantomcircuit [~phantomci@strateman.ninja] has joined #bitcoin-core-dev 15:31 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Quit: Leaving.] 15:56 -!- Tera2342 [~Tera2342@171.5.153.152] has joined #bitcoin-core-dev 16:03 -!- Tera2342 [~Tera2342@171.5.153.152] has quit [Ping timeout: 272 seconds] 16:04 -!- Tera2342 [~Tera2342@171.5.153.152] has joined #bitcoin-core-dev 16:09 -!- JackH [~Jack@host-80-43-141-42.as13285.net] has joined #bitcoin-core-dev 16:19 -!- brg444 [46346d00@gateway/web/freenode/ip.70.52.109.0] has quit [Ping timeout: 252 seconds] 16:19 -!- brg444 [46346d00@gateway/web/freenode/ip.70.52.109.0] has joined #bitcoin-core-dev 16:39 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev 16:40 -!- Tera2342 [~Tera2342@171.5.153.152] has quit [Read error: Connection reset by peer] 16:44 -!- brg444 [46346d00@gateway/web/freenode/ip.70.52.109.0] has quit [Ping timeout: 252 seconds] 16:49 -!- Tera2342 [~Tera2342@171.5.153.152] has joined #bitcoin-core-dev 16:51 -!- JackH [~Jack@host-80-43-141-42.as13285.net] has quit [Ping timeout: 260 seconds] 16:55 < Luke-Jr> cfields: yeah, but I'm not finding any practical way to do that. 16:56 < cfields> Luke-Jr: worked fine in my local test.. 16:56 < cfields> PYTHONPATH=$(PYTHONPATH) python foo 16:56 < Luke-Jr> cfields: well, if the user is overriding PYTHONPATH, presumably they want it used with any program during the build process.. 16:57 < cfields> Luke-Jr: yes, so make sure it's invoked like that any time python is used 16:58 < cfields> or more easily, just export it from the makefile 16:58 < Luke-Jr> is that portable? and would we need to do it in every makefile? 16:58 < cfields> should be portable, yes. no, all makefiles are included from the top one 16:59 < cfields> well, all in src/ anyway 16:59 -!- jrmithdobbs [~dhuff@50.250.201.254] has joined #bitcoin-core-dev 16:59 < jrmithdobbs> i'm sorry, that was poorly executed. That is all. 17:00 < jrmithdobbs> my bad. 17:01 -!- jrmithdobbs [~dhuff@50.250.201.254] has quit [Client Quit] 17:01 -!- jtimon [~quassel@74.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 17:07 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 246 seconds] 17:11 -!- jcorgan|away is now known as jcorgan 17:30 -!- brg444 [46346d00@gateway/web/freenode/ip.70.52.109.0] has joined #bitcoin-core-dev 17:31 -!- zookolaptop [~user@2601:281:8001:26aa:f823:7965:aaca:8589] has quit [Remote host closed the connection] 17:34 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev 17:36 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-jvqeveqtqotuubrf] has quit [Ping timeout: 255 seconds] 17:37 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-eylytmwuvrzyhspn] has quit [Ping timeout: 264 seconds] 17:38 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-lgljkdtdaupqtklr] has joined #bitcoin-core-dev 17:39 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ufjgphemvoozuxya] has joined #bitcoin-core-dev 17:54 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ufjgphemvoozuxya] has quit [Quit: Connection closed for inactivity] 17:59 -!- brg444 [46346d00@gateway/web/freenode/ip.70.52.109.0] has quit [Ping timeout: 252 seconds] 18:00 -!- dermoth [~thomas@dsl-216-221-62-176.mtl.aei.ca] has quit [Read error: Connection reset by peer] 18:00 -!- dermoth [~thomas@dsl-216-221-62-176.mtl.aei.ca] has joined #bitcoin-core-dev 18:02 -!- blade [~blade@99-139-66-139.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev 18:03 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Quit: .] 18:04 < blade> my transactions are not being confirmed whats going on 18:04 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev 18:05 < blade> its been over an hour 18:06 < blade> im useig the bitcoin core wallet 18:07 < jcorgan> blade: this is not the correct channel for this, please go to #bitcoin 18:07 < blade> ok ty 18:08 -!- blade [~blade@99-139-66-139.lightspeed.sntcca.sbcglobal.net] has left #bitcoin-core-dev ["Leaving"] 18:18 < GitHub106> [bitcoin] jrmithdobbs closed pull request #7243: This community NEEDS to adopt a code of conduct. Recent events make t… (master...code_of_conduct) https://github.com/bitcoin/bitcoin/pull/7243 18:18 -!- Yoghur114_2 [~jorn@g227014.upc-g.chello.nl] has quit [Remote host closed the connection] 18:29 -!- BashCo_ [BashCo@gateway/vpn/mullvad/x-rbntkhcyxajbivpw] has quit [Ping timeout: 255 seconds] 18:31 -!- dhuff [~dhuff@50.250.201.254] has joined #bitcoin-core-dev 18:34 -!- dhuff is now known as jrmithdobbs 18:41 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev 18:44 -!- Tera2342 [~Tera2342@171.5.153.152] has quit [Ping timeout: 240 seconds] 18:47 -!- raedah [~raedah@mf40536d0.tmodns.net] has quit [Quit: Leaving] 18:50 < jrmithdobbs> I just wanted to say again that I am sorry for that shit storm and thank you guys for what you do. 18:51 -!- jrmithdobbs [~dhuff@50.250.201.254] has quit [Quit: jrmithdobbs] 18:53 -!- xiangfu [~xiangfu@111.198.29.54] has joined #bitcoin-core-dev 19:06 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 265 seconds] 19:30 -!- xiangfu [~xiangfu@111.198.29.54] has quit [Ping timeout: 256 seconds] 19:30 < dcousens> jtimon: that came out wrong 19:30 < dcousens> I meant, that is certainly the dream, but, I don't think its where bitcoin/bitcoin is headed 19:31 < dcousens> At least, that opinion is based on the last time I spoke about it 19:33 < jtimon> dcousens: it is certainly where Bitcoin JT is headed :p 19:33 < dcousens> jtimon: haha 19:33 < dcousens> Just realised as I re-read my comment, that it might have come across as "your dreaming buddy" 19:34 < dcousens> when really it was more along the lines of "I hope so to, but, even this PR is having trouble :P" 19:34 < jtimon> it came across just like Luke-Jr's later "I like that but seems out of scope for this PR" 19:35 < jtimon> I literally mean just replacing the ints with strings for now 19:36 < dcousens> I think its worth suggesting, but, theres still the concept which needs to be reach ACK'd status before the syntax is wortwhile 19:38 -!- xiangfu [~xiangfu@111.198.29.54] has joined #bitcoin-core-dev 19:38 < jtimon> maybe I should make clear that I will maintain a branch with equivalent functionality on top of major releases starting with 0.12 regardless of the PR being merged or not? 19:38 < dcousens> I think people will certainly look to that PR for a simple patch set 19:41 < jtimon> yeah, I will just do free a back-and-forward-port service of the PR with my nits squashed 19:54 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev 19:55 < midnightmagic> jtimon: You mean with full-RBF as an option? 19:56 < jtimon> both fullrbf and firstseen, just like the PR (and then, hopefully more) 19:57 < midnightmagic> jtimon: if you want someone to gitian it with you let me know, i'd be happy to an i have plenty of build capacity 19:58 < jtimon> midnightmagic: that's great to know, my plan was to have only a source repo, but if you gitian it, that would be awesome 19:59 -!- p15 [~p15@122.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-core-dev 20:10 < jtimon> Luke-Jr: didn't pblocktemplate->vTxSigOps[0] used to count p2sh sigops too ? 20:10 < Luke-Jr> jtimon: yes, it's supposed to 20:11 < jtimon> so that's what you mean when you say that you won't be able to recommend 0.12 for mining? 20:12 < morcos> jtimon: it still does or there is a bug 20:12 < morcos> but i'm pretty sure there isn't, b/c in checking that blocks were the same i verified that the sigop count was the same 20:15 < morcos> oh [0], i missed that. i don't think i changed that line. 20:15 < jtimon> in last-0.12.99 3cd836c1 I see pblocktemplate->vTxSigOps[0] = GetLegacySigOpCount(pblock->vtx[0]); 20:16 < morcos> yeah, i think thats what its like in 0.11 too 20:16 < morcos> yep 20:16 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 240 seconds] 20:17 < jtimon> yeah, that's not changed in 553cad94 20:18 < jtimon> Luke-Jr: is it supposed to count p2sh sigops or not? 20:18 < morcos> its probably meaningless the way its used in practice, because a p2sh script isn't used as the coinbase dummy argument 20:18 < Luke-Jr> jtimon: yes 20:18 < Luke-Jr> it's supposed to be everything to total to the sigoplimit 20:21 < jtimon> Luke-Jr: but https://github.com/bitcoin/bitcoin/blame/master/src/miner.cpp#L289 it's there from the creation of miner.cpp 20:25 < jtimon> oh that's only for the coinbase, never mind 20:25 < jtimon> sorry, metal furt 20:25 < jtimon> mental 20:45 < Luke-Jr> [04:11:29] so that's what you mean when you say that you won't be able to recommend 0.12 for mining? <-- by this I mean, removal of priority policy support 20:46 < Luke-Jr> note the current status quo is not merely "disabled by default", because the new implementation is still buggy 20:46 < Luke-Jr> (status quo in master, I mean, not the network) 20:49 < jtimon> I'm mostly interested in your opinion on last-0.12.99 3cd836c1 20:50 < jtimon> Luke-Jr: ie what you think that needs to be solved for 0.12 20:51 < Luke-Jr> the big things IMO are 1) ability to configure RBF policy (high demand from users); 2) fix policy support; 3) restore sane default setting for policy size 20:52 * Luke-Jr looks over PR list to make sure he didn't miss anything too important 20:52 < Luke-Jr> bytespersigop may be a good idea, and is tagged for 0.12 20:53 < Luke-Jr> but technically not a fix 20:58 < jtimon> oh, you expect the optional fullrbf to be backported to 0.12 ? 20:59 < jtimon> I mean, I wouldn't oppose 20:59 < Luke-Jr> yes, that was something many people expected to be part of the original PR.. 21:00 -!- dermoth [~thomas@dsl-216-221-62-176.mtl.aei.ca] has quit [Read error: Connection reset by peer] 21:00 < Luke-Jr> I consider it a bug that it's not configurable right now. 21:01 < jtimon> well, I consider it it cheap-to-maintain missing functionality, but we agree overall 21:01 < Luke-Jr> 7217 and 7213 also stand out as bugfixes that perhaps ought to get into 0.12 21:02 < jtimon> I guess the difference is that I would be happy if it was merged in master but not backported to 0.12 21:02 -!- dermoth [~thomas@dsl-216-221-62-176.mtl.aei.ca] has joined #bitcoin-core-dev 21:02 < Luke-Jr> many people I spoke to (on reddit especially) found the RBF changes acceptable only knowing it was configurable 21:04 < jtimon> I think we should have supported fullrbf optionally and firstseen as default ages ago, maybe opt-in rbf wouldn't have been necessary 21:05 < Luke-Jr> well, in general I think opt-in was a good improvement. but not if it entails developers trying to control users. 21:07 < jtimon> yeah, I agree opt-in is a great solution to the dilema, I'm just pointing out that for me there wasn't a dilema in the first place, if there's controversy, that's more of a reason to offer both sides of the local policy controversy so that people can choose 21:08 < jtimon> I hope this doesn't get rejected under the "controversial syndrome" btcdrak once talked me about 21:10 < sipa> Luke-Jr: all fine with making optin configurable 21:10 < sipa> i am not fine with adding full rbf support 21:10 < Luke-Jr> sipa: it's not your place to decide. 21:10 < sipa> sure it is 21:10 < sipa> it is not my place to decide what people run 21:10 < Luke-Jr> no, it is the end-user's right to decide. 21:11 < sipa> it is my place to decide what i want the software that i am maintainer of to encourage 21:11 < jtimon> sipa: why -policy=firstseen is fine but -policy=fullrbf is not? 21:11 < sipa> jtimon: it breaks a social contract 21:11 < Luke-Jr> it breaks no social contract. -.- 21:11 < jtimon> what social contract? 21:12 < sipa> whether you like it or not, some people see transactions as implicitly promising to not double spend 21:12 < jtimon> this is policy, -policy=firstseen users must accept that they can't do anything about me running -policy=fullrbf (and viceversa) 21:12 < Luke-Jr> RBF does not change that. 21:12 -!- Greyboy [~meat@unaffiliated/greyboy] has quit [Ping timeout: 240 seconds] 21:12 < sipa> we can explain to people that this is a bad idea, but it does not change the expectation 21:13 < sipa> and we just made that promise stronger by giving a way to opt out of it 21:13 < jtimon> sipa: and they are free to use firstseen, whatever they like it or not, there's people that prefer fullrbf 21:13 < jtimon> and they can't do anything to stop them 21:13 < sipa> jtimon: absolutely! 21:13 < Luke-Jr> Opt-in RBF does not opt out of the implied promise not to fraudulently double-spend 21:13 < sipa> but i don't think we should encourage it either 21:14 < sipa> Luke-Jr: imho it does 21:14 < Luke-Jr> sipa: that's ridiculous. 21:14 < Luke-Jr> those promises are part of society, not the protocol 21:15 < jtimon> ok, but let's not make another bool please, let's do -policy=firstseen -policy=optinrbf even if bitcoin core insists on having people like petertodd publishing parallel releases 21:16 < jtimon> it will be cleaner for me to add the -policy=fullrbf option in bitcoin JT 0.12 21:16 < jtimon> Luke-Jr: I think he means bitcoin core did the promise, not the protocol 21:16 < Luke-Jr> jtimon: any interest in combining efforts perhaps BTW? maybe Bitcoin LJR + Bitcoin JT can merge to some not-so-personal name? 21:18 < jtimon> I would be happy to collaborate with you in bitcoin-policy if that makes sense to you 21:19 < jtimon> as long as it starts with something like #6423 21:20 < jtimon> but I'm still recovering from #5595/#6068's depression... 21:21 < Luke-Jr> jtimon: I suspect the key thing to merging our forks will be whether the changes you want conflict in unresolvable ways with the ones I want. 21:23 < jtimon> and sorry for being sincere, but you're partly responsible of me being so disappointed about that, I would have happily s/CStandardPolicy/CDefaultPolicy/ or added a TODO to some of the interface methods documentation to say it's incomplete months ago, but not when I closed it , for my own sanity 21:23 < btcdrak> sipa, luke-jr, we should just leave rbf as it is for now 21:24 < btcdrak> rbf will come slowly. it wont come by trying to push too fast 21:24 < jtimon> if you want to collaborate with me on this bitcoin-policy branch you'll have to learn to nit faster, because I already have Bitcoin Core for when I'm fine waiting 21:24 < sipa> agree 21:25 < jtimon> btcdrak: sipa: ok, but let's not make another bool please, let's do -policy=firstseen -policy=optinrbf even if bitcoin core insists on having people like petertodd publishing parallel releases 21:25 < sipa> jtimon: totally fine with that 21:26 < jtimon> Luke-Jr: would you be fine with that for #7219 ? 21:27 < Luke-Jr> jtimon: using -policy now, locks us in to the syntax for it; I don't know that the final syntax is so obvious 21:27 < jtimon> supporting -policy=firstseen and -policy=optinrbf, but not -policy=fullrbf (yet, we can do that on our branch for now) 21:28 < jtimon> well, in #6423 I was preparing for different policies to be able to have different attributes and command-line options dynamically 21:29 < jtimon> (even if most policies just use specific default values for parameters in CDefaultPolicy) 21:29 < Luke-Jr> hmm, so -policy would be kind of a "load this module" type logic? 21:30 < jtimon> see also #5180 21:30 < Luke-Jr> jtimon: how would you propose users select opt-in FSS? 21:30 < jtimon> optin FSS? 21:30 < jtimon> what is that? 21:30 -!- desantis [~desantis@68.66.103.249] has quit [Quit: desantis] 21:30 < sipa> fss rbf? 21:31 < Luke-Jr> jtimon: first-seen-safe RBF only with the opt-in flag 21:31 < jtimon> I was thinking of maybe cpfp variations as more potential options, or maybe just a parametrizable cpfp class that extends CDefaultPolicy 21:33 < sipa> can we just stop doing dozens of policies that nobody asks for? 21:33 < sipa> i understand that you'd want to disable rbf 21:33 -!- Tera2342 [~Tera2342@171.5.153.152] has joined #bitcoin-core-dev 21:36 < Luke-Jr> sipa: that implies we should do policies that people *do* ask for.. like priority space and full RBF 21:36 < jtimon> sipa: now we're talking about our potential collaboration (or Bitcoin JT if Luke-Jr cannot commit to the "nit early, nit often" principle) in which I'm interested in exposing as many policies as possible (just to prove the reusability of the underlying Cpolicy interface) 21:37 < Luke-Jr> jtimon: unfortunately, I don't think I can commit to that, due to time constraints. 21:37 < sipa> Luke-Jr: yes, i would like to support priority space; that's just an engineering tradeoff that it is hard to maintain; i am willing to promise that i'll personally look into a replacement 21:38 < sipa> Luke-Jr: full rbf makes no sense for a full node unless miners do it 21:38 < Luke-Jr> sipa: I'm pretty sure there are miners who do ti. 21:38 < sipa> Luke-Jr: once they do, i'm sure we can even discuss it as default policy in bitcoin core 21:39 < sipa> once they do in significant numbers 21:40 < Luke-Jr> wangchun: ^ willing to take the heat? :P 21:41 < jtimon> Luke-Jr: that shouldn't be an impediment, bitcoin-policy can be just the subset of bitcoin JT related to policy that you are happy with when you have time to be happy with it, not in a hurry for review anymore since this is going to be on top of 0.12 instead of master (I don't plan to PR anything policy-related until all the consensus code is encapsulated in a single building module independent from storage in master) 21:41 < Luke-Jr> sipa: a replacement for the priority area would be nice, but until it exists and is well-tested, it isn't reasonable to remove the existing, working policy there 21:42 < btcdrak> Luke-Jr: imo the best way for rbf is we release as is with optin full enabled, after 6-12 months after wallets have adapted and people see the world hasnt exploded, then we can propose a move to full full 21:42 < btcdrak> petertodds optin full rbf is a political compromise 21:42 < btcdrak> as was fssrbf 21:42 < btcdrak> baby steps... 21:42 < Luke-Jr> btcdrak: it wouldn't bother me as much, if it wasn't a pattern moving from "work toward increasing policy options" to "remove policy options and make them harder to develop" 21:43 < jtimon> btcdrak: maintaining the optional -policy=firstseen shouldn't be more controversial than not doing it 21:46 < jtimon> maybe -policy=default is better than -policy=optinrbf, but that is more resuable code and shouldn't be more controversial 21:47 < jtimon> or I don't see how unless we support -policy=fullrbf in core, but as said I'm not concerned about maintaining that in a separate branch, it should be much easier to rebase to the next major release from now on than it was before for petertodd 21:49 < jtimon> let's not support it on github/bitcoin, but it would be good that people understand that is going to be supported anyway, even if they don't like that 21:50 < jtimon> just like we fullrbf supporters understand that firstseen is going to be supported (in my case, I really want it to be supported) 21:52 < jtimon> just from the noise in the PR, I believe there's demand for firstseen, and I haven't seen anyone opposing to expose that, only some people opposing to fullrbf 21:52 < Luke-Jr> if we're going to deny an option to full-full-RBF users, it makes just as much sense to deny the option to no-optin-RBF users. neither opinion has a more logical basis than the other, so we shouldn't play favourites in this extreme. 21:54 < jtimon> well, although I agree that both parts in the policy-discussion should be treated equally (not necessarily with defaults) I guess the difference is that firstseen was the policy that was previously available 21:55 < jtimon> anyway, I would like to understand your opinion on the special-space better too 21:55 -!- p15_ [~p15@118.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-core-dev 21:57 < Luke-Jr> jtimon: you mean priority? 21:57 < jtimon> when I ask what's the use case you keep saying "to support the current policy", but I don't see how the current policy cannot be implemented with a unified metric, even if it's time dependent (which may have performance costs) 21:57 < jtimon> but there's no need for a separated space 21:57 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev 21:58 -!- p15 [~p15@122.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 256 seconds] 21:58 < Luke-Jr> jtimon: by considering the feerate together with priority, it exposes the policy to feerate-based attacks (which are clearly a "when", not "if") 21:59 < jtimon> yep, you could have a g(f(fees, size), priority) "fitness function" for transactions without special space 21:59 < Luke-Jr> and then when someone games the fees, the whole block is spam and legit users are blocked 22:00 < jtimon> no, you can create an heuristic function that is equivalent to any policy you can think of based on separated spaces, that should be methematically provable (not that I can do it right now) 22:00 < jtimon> no, when I say equivalent I mean equivalent 22:01 < aj> jtimon: only if you adjust g() based on what transactions are available 22:01 < Luke-Jr> jtimon: that's at the very least much more complex to implement 22:01 < sipa> jtimon: that's not the case unless you're willing to recompute virtual fees after every tx 22:01 < jtimon> aj correct, that only seems a performance challenge 22:01 < Luke-Jr> the goal ought to be to make policies *easier* to write, not absurdly complicated 22:02 < sipa> Luke-Jr: how about we introduce a new scripting language then to configure relay and minig policies? 22:02 < sipa> we still have engineering tradeoffs to makr 22:02 -!- go1111111 [~go1111111@104.232.116.217] has joined #bitcoin-core-dev 22:03 < jtimon> aj not a code complexity one, we can maintain an optional functional-equivalent-but-far-less-performant version of "the current policy" with reduced maintainence costs, if someone wants to maitain the re-optimizations that's another topic 22:03 < Luke-Jr> sipa: that's basically my long-term goal 22:03 < Luke-Jr> minus it being a new language.. no reason not to allow using existing ones 22:05 < jtimon> the goal of my branch is to offer as much functionality as possible as a showcase that the refactors behind it actually make the code more reusable and maintainable, not necessarily that all particular optional functionalities are suppported in the most optimal way 22:05 < sipa> maintainable code is a worthy goal, and that's the extent of my support for policy refactors 22:06 < sipa> i don't agree with the extreme configurability of policy as a goal 22:06 < GitHub50> [bitcoin] luke-jr closed pull request #7219: Make RBF policies optional (master...rbf_opts) https://github.com/bitcoin/bitcoin/pull/7219 22:06 < jtimon> no, extreme configurability is the means 22:07 < sipa> extreme runtime configurability i mea 22:07 < jtimon> it doesn't need to get into master, but a -policy= is, I think, not that much to ask (and could save us some new bool command-line options in the future) 22:08 < sipa> making policy changes easy to write is indeed a good way to verify the modularization you're obtained 22:08 < jtimon> yes, yes, I mean the same, the goal is software quality, extreme runtime configurability is kind of a test to reusability 22:09 < sipa> ok, agree! 22:10 < aj> jtimon: hmm, if you want to define your own g() and make it vary depending on the remainder of the mempool, maybe the way to do that is with a generic update_mempool_tx_score rpc call, and writing the actual logic externally in python/etc? 22:10 < jtimon> that's why I'm intersted on what luke really wants behind its defense of the separate space, because I find "the current policy" uninteresting to support in terms of reusability, I cannot think of another policy that is not time dependent and requires a separated space 22:11 < jtimon> aj: well, I would just start with a CPolicy abstract class 22:12 < jtimon> or a -policy= command line option would also help 22:13 < jtimon> but yeah, we could have -policy=rpc_mempool_score_update, shouldn't be hard 22:14 < jtimon> and it could have different command-line parameters also configurable via GUI 22:16 < jtimon> s/requires/"requires" 22:17 < jtimon> so I would like to know more from luke about what's so great about not checking any minimum fee for some transactions 22:19 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 256 seconds] 22:21 < jtimon> aj in other words: 22:21 < jtimon> def g(tx) 22:21 < jtimon> if reason(tx.fees, tx.size) < reason_plus_ddos(mempool, tx): 22:21 < jtimon> return false 22:21 < jtimon> if priority < simulate_separate_space(tx, whatever) 22:21 < jtimon> return false 22:22 < jtimon> return true 22:22 < phantomcircuit> Luke-Jr, i agree with jtimon that the cli parameter should be a string 22:22 < jtimon> if priority(tx) < simulate_separate_space(tx, whatever) 22:23 < Luke-Jr> phantomcircuit: comma-separated? 22:23 -!- zookolaptop [~user@2601:281:8001:26aa:20e8:31a2:73f3:9798] has joined #bitcoin-core-dev 22:23 -!- p15_ [~p15@118.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 276 seconds] 22:23 < phantomcircuit> Luke-Jr, rbf policy option should be a string not 0,1,2 22:24 < phantomcircuit> (just noticed you closed it, so nvm) 22:25 < Luke-Jr> phantomcircuit: how do you specify both FSS and optin? 22:25 < Luke-Jr> phantomcircuit: "nvm" is unnecessary, as this is still going in LJR 22:26 < phantomcircuit> Luke-Jr, specify the parameter twice 22:26 < aj> jtimon: the thing with priority is you can't just rely on choosing where in the order to insert the tx initially; you have to re-sort the old transactions as time passes. with an rpc set_mempool_tx_score call you could do that, but you'd still have to apply it to an individual transaction repeatedly while it sits in the mempool 22:26 < phantomcircuit> isn't it implemented as a multimap anyways? 22:26 < Luke-Jr> ew 22:26 < jtimon> no!!! 22:27 < jtimon> -policy=a, -policy=b, -policy=a_and_b: that's how you do a_and_b 22:27 < jtimon> I mean, how you support it in parallel to only_a and only_b 22:28 -!- p15 [~p15@39.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-core-dev 22:28 < Luke-Jr> jtimon: that isn't going to scale 22:28 < jtimon> I still don't think I undesrstand firstseen 22:28 < jtimon> I still don't think I undesrstand firstseen_optinrbf, isn't that the same as optinrbf? 22:28 < Luke-Jr> no, it isn't. 22:29 < Luke-Jr> why would you use underscores instead of commas? 22:29 < phantomcircuit> Luke-Jr, meh, internally it's a bitfield presented to the user as -policy=A -policy=B 22:30 < jtimon> Luke-Jr: well, some policies must die so that others can be maintained in parallel to the default one, infinite configurability forever certainly doesn't scale 22:31 < jtimon> the goal of bitcoin-policy could be to support the most interesting ones that are relatively easy to rebase from the latest major release, or that can be easily added in the current one 22:34 < Luke-Jr> … 22:34 -!- zookolaptop [~user@2601:281:8001:26aa:20e8:31a2:73f3:9798] has quit [Ping timeout: 250 seconds] 22:34 < jtimon> Luke-Jr: re why would you use underscores instead of commas? 22:34 < jtimon> I would use # or @, of course, (ie -policy=a#and#b), but I thought underscores were the new trend 22:34 < Luke-Jr> more user-friendly to use commas 22:34 < Luke-Jr> since it's being parsed into multiple options 22:36 < jtimon> the point is, once it is a string, I don't f#$%^ care what symbols you prefer as long as they play well with the command line (ie not -policy=m-y-p-o-l-i-c-y) 22:39 < jtimon> and the other point is, I undesrtand -policy=firstseen and -policy=optinrbf, but not -policy=firstseen,optinrbf 22:40 < jtimon> (or -policy=firstseen_optinrbf, whatever) 22:40 < sipa> aj: s/set_mempool_tx_score/prioritizetransaction/ 22:41 < sipa> aj: it already exists :) 22:41 < jtimon> sipa: oh, that's what is for? 22:42 < aj> sipa: (prioritise with an s, apparently!) 22:42 < sipa> british vs american :) 22:42 < sipa> i never know which is which 22:42 < sipa> so i just pick the shortest 22:42 < btcdrak> s is british 22:42 < dcousens> ^ 22:42 < btcdrak> british is the original <<<<<< 22:43 * btcdrak grins 22:43 < btcdrak> I think it's the status quo in software to use the American spelling 22:43 < dcousens> pretty much 22:43 < btcdrak> I dislike that fact a lot... 22:44 < dcousens> I gave up on `s` in favour of `z`, and almost never use `u` 22:44 < aj> sipa: yeah, that seems sufficient, would be a bit painful to use for externally hacking priority back in 22:45 < dcousens> jtimon: would it ever be worth policy being that 'plug and playable' though? 22:45 < dcousens> like, unless you're a miner, or doing it for hardware reasons 22:45 < jtimon> dcousens: as aj suggests? I don't know seems it would be very slow 22:46 < dcousens> you're almost better off just capturing everything 22:46 < dcousens> having your policy mimic miners is great for having an insight into what could be included in the next block 22:47 < dcousens> but, its entirely speculative 22:47 < jtimon> I would chose whatever option it's easier to maintain, if only I had an intersting use case (I just don't think free transactions are an interesting use case) 22:50 < jtimon> in fact, I believe I will just remove the free tx special case from bitcoin-consensus-policy-jt, so it doesn't beelong in the bitcoin-policy-luke-jt common branch 22:53 < wangchun> Luke-Jr: But I think for cafe-like small businesses, 0-conf is already unsafe as the block becoming full 22:53 < Luke-Jr> wangchun: unconfirmed transactions are absolutely unsafe, I agree 22:54 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 22:54 < wangchun> If a customer pays the bill with a no-fee tx, what should the cashier do? It probably never get confirmed 22:56 < wangchun> And for priority space, if the block is not approaching to max block size, I would like to include some free tx in my block 22:56 < Luke-Jr> wangchun: well, he can always CPFP it 22:56 < Luke-Jr> and yes, priority will eventually make it eligible for charitable miners 22:56 < wangchun> but if the block is already full, why should I still sort some tx by priority? 22:56 < wangchun> That is why I used minblocksize=250000 before 22:56 < Luke-Jr> wangchun: well, what about if there is a spam attack with fees? 22:56 < Luke-Jr> like in the summer 22:58 < wangchun> I have to set limitfreerelay to zero because I am aware some of my tx to be dropped randomly from mempool due to one patch recently get merged 22:58 < wangchun> I am glad to hear how to disable this "feature", however. 22:59 < wangchun> Luke-Jr: As you have suggested before, set minblocksize to 250k may open a door to spammers 22:59 < wangchun> CPFP should solve cafe owner's problem 23:01 < Luke-Jr> wangchun: no, I mean like over the summer, when spammers backlogged with paying fees 23:01 < Luke-Jr> wangchun: if you put fees first, you would mine those before priority txs 23:01 < maaku> wangchun: it is only a matter of time until mempools are always full 23:04 < wangchun> maaku: that's why we have limitfreerelay to zero 23:05 < maaku> wangchun: no matter your parameters. bitcoin usage will grow to exceed capacity. this is the expected outcome 23:05 < wangchun> But if any devs could tell me how to disable the mempool tx dropping feature, I would like to increase limitfreerelay value to 3 or 5 which should help no-fee tx 23:06 < wangchun> also priority size should decrease as the block template is approaching max block size 23:07 < wangchun> Maybe I should write the patch 23:08 < sipa> wangchun: the mempool limiting will only drop the lowest fee transactions, quite intelligently 23:08 < wangchun> Luke-Jr: What's your attitude toward priority size? 23:08 < sipa> wangchun: the solution is just to increase the size of the mempool 23:08 < wangchun> sipa: I know, but we have the most important tx the lowest prioirty.. 23:08 -!- tripleslash_h [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev 23:08 < wangchun> sipa: so I must switch off this feature 23:08 < sipa> wangchun: that i don't understand 23:08 < Luke-Jr> wangchun: I think it should be non-zero :p 23:09 < wangchun> sipa: I have a txt which has a list of tx we must confirm at the highest prioirty 23:09 < wangchun> sipa: this txt file is read every time createnewblock is called 23:09 < sipa> wangchun: you can use prioritisetransaction ? 23:09 < wangchun> sipa: but the tx themselves in mempool remain their priority untouched 23:09 < wangchun> sipa: prioritisetransaction does not persist 23:09 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 246 seconds] 23:10 < wangchun> sipa: and it cannot be edited with vim 23:10 < sipa> wangchun: across restarts it does not 23:10 < Quent> if blocks are full is it not easy to ddos spam the system so increasing the fee short term to unbearable amounts? 23:10 < Quent> I think someone has some maths to show it too... 23:11 < sipa> wangchun: it'd be pretty easy to hook up the reading of that file with the prioritization inside the mempool that prioritisetransaction does too 23:12 < sipa> wangchun: which will automatically make those transactions ineligible for eviction 23:12 < wangchun> sipa: I don't know how often it is called, reading files is expensive i suppose 23:13 -!- raedah [~raedah@mf40536d0.tmodns.net] has joined #bitcoin-core-dev 23:13 < sipa> wangchun: i haven't seen your code; i'm just saying that the two mechanisms should easily combinable 23:13 < Quent> http://www.metzdowd.com/pipermail/cryptography/2015-December/027568.html 23:13 < wangchun> sipa: but if you point me the git rev of the tx-dropping patch, that would help 23:13 < sipa> wangchun: just increase the mempool size to whatever you can support 23:14 < wangchun> sorry I have to leave, check irc log later 23:14 < sipa> wangchun: -maxmempool=10000 will give you a max 10G menpool 23:14 < sipa> wangchun: so set it to whatever amount of memory you can support; if it's still higher you'd go oit of memory anyway 23:14 < sipa> wangchun: anyway, feel free to ping here more if you have questions 23:21 < dcousens> sipa: with segwit, a rescan is only possible with all the witness data no? 23:24 -!- raedah [~raedah@mf40536d0.tmodns.net] has quit [Quit: Leaving] 23:30 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-povzhzxgwuybneyz] has joined #bitcoin-core-dev 23:41 < sipa> dcousens: no 23:41 < sipa> dcousens: i hadn't thought about that, but you can rescan without witnesses 23:49 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev 23:52 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev 23:52 < dcousens> sipa: how so? 23:53 < sipa> dcousens: why do you need signatures? 23:54 < sipa> the amounts, addresses, consumed coins, locktime, ... are what matters to your wallet 23:54 < dcousens> sipa: I don't, but, I might need the output scripts, and if they are (not always, but maybe) in the seg wit data too 23:55 < sipa> dcousens: output scripts only matter for payments to yourself, and for those you know the full script anyway 23:55 < sipa> the witnesses are for inputs, not for outouts 23:55 < sipa> it's the same as p2sh 23:56 < dcousens> yeah, I guess I'd just watch for the sigwit hash that matched the P2PKH equivalent script 23:56 < sipa> you don't need to know the redeemscripts to analyse p2sh ouputs to your wallet either 23:56 < dcousens> nvm, ta 23:56 < sipa> not the equivalent; your wallet would know it gave out a segwit script, and explicitly look for that 23:56 < dcousens> sipa: a fresh import wouldn't know 23:57 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 23:57 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 23:58 < sipa> dcousens: why not? you'd need to import scripts just as with p2sh 23:58 < sipa> before import