--- Day changed Fri Dec 11 2015
00:00 < Luke-Jr> http://luke.dashjr.org/tmp/code/DS_Store
00:12 < jonasschnelli> Luke-Jr: it looks like its easier to test if you add it to your PR (i can do a gitian build). Okay?
00:12 < Luke-Jr> ok, pushed
00:14 < jonasschnelli> Okay. Building caa7c8fabef027b9640561dff8472766f5e3296d (takes 30-40mins)
00:14 < Luke-Jr> jonasschnelli: that's not the top commit
00:14 < jonasschnelli> Sorry. Meant: c903ae4d6794bb448d72100744036b7835481450
00:15 < jonasschnelli> I skip win and linux builds... so 12mins will it be~.
00:17 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
00:18 -!- MarcoFalke [c3523fc9@gateway/web/cgi-irc/kiwiirc.com/ip.195.82.63.201] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
00:19 < wumpus> gmaxwell: so should we revert #4906?
00:23 < GitHub187> [bitcoin] laanwj closed pull request #7196: Doxygen (master...doxygen-a) https://github.com/bitcoin/bitcoin/pull/7196
00:25 < GitHub39> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5dc63ed1ca8a...f7f44b1bdd15
00:25 < GitHub39> bitcoin/master 00423e1 Suriyaa Kudo: Set link from http:// to https://...
00:25 < GitHub39> bitcoin/master f7f44b1 Wladimir J. van der Laan: Merge pull request #7197...
00:25 < GitHub16> [bitcoin] laanwj closed pull request #7197: Set link from http:// to https:// (master...patch-1) https://github.com/bitcoin/bitcoin/pull/7197
00:30 < jonasschnelli> Luke-Jr: seems to have build issues on OSX: https://bitcoin.jonasschnelli.ch/pulls/7192/build-osx.log
00:31 < Luke-Jr> your SSL is still broken :/
00:31 < jonasschnelli> Yes. I know... need to fix it. Will do *soon*.
00:32 < Luke-Jr> I guess I can hopefully reproduce it in gitian myself :x
00:33  * Luke-Jr wonders why gitian has started demanding he enter a password
00:35 < Luke-Jr> debug1: Skipping ssh-dss key ./var/id_dsa for not in PubkeyAcceptedKeyTypes
00:42 < wumpus> bleh, can you bisect it to a change in gitian?
00:42 < Luke-Jr> looks like it's OpenSSH 7.0
00:43 < Luke-Jr> no longer accepts DSS keys by default
00:43 < wumpus> oh that's good to know
00:44 < Luke-Jr>  * Support for ssh-dss, ssh-dss-cert-* host and user keys is disabled by default at run-time. These may be re-enabled using the instructions at http://www.openssh.com/legacy.html
00:44  * wumpus quickly checks if he has any servers/VPSes with dss keys he could lose access to
00:48 -!- moli [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer]
00:48 < Luke-Jr> looks like I'm updating Qt in gitian
00:49 < wumpus> also wonder why gitian insists on creating a dsa key in the first place
00:50 < Luke-Jr> devrandom: ^
00:51 < gmaxwell> it would be fast.
00:52 < wumpus> maybe switch to ssh-ed25519
00:53 < gmaxwell> I dunno how widely supported that is, but perhaps that doesn't matter. E.g. centos won't have support for it.
00:54 < wumpus> what matters for gitian is what ubuntu versions support it, at least 14.04 does, but don't know if e.g. 12.04 does
00:56 < wumpus> then again, as this is only used to communciate with a vm on the local host, may be good enough to just add the force-use-dss option. Heck, using no cipher and auth would probably be acceptable...
00:57 < gmaxwell> or just set it to use 2kbit rsa, the generation time is probably not that bad on anything that can compile bitcoin.
00:57 < wumpus> (using ssh to communicate with something running on localhost is kind of redundant :-) )
00:58 < wumpus> changing that would mean regenerating all the base images though
01:03 < wumpus> Luke-Jr: if you change the ssh line in libexec/on-target to include -oHostKeyAlgorithms=+ssh-dss , does that work around the issue?
01:03 < Luke-Jr> you want PubkeyAcceptedKeyTypes=+ssh-dss
01:04 < wumpus> ok
01:05 < wumpus> but in this case it's about what your ssh *sends*, not what is accepted, which shouldn't have changed
01:06 < wumpus> none of the ubuntu versions used for gitian building has OpenSSH 7.0+, it must be the outer ssh refusing to send a dss key
01:07 < Luke-Jr> yes
01:08 < wumpus> so does it work?
01:08 < Luke-Jr> yes
01:09 < wumpus> great
01:16 < Luke-Jr> ugh, the build failure blocks caching the Qt? :/
01:18 < wumpus> yes that's kind of annoying
01:18 < wumpus> any build failure prevents caching of anything
01:19 < wumpus> cached dependencies are not handled separately from the build product, if it fails, it fails completely
01:20 < wumpus> may be possible to split up between a descriptor that just builds the dependencies and one that builds bitcoin, or some other trick
01:21 < wumpus> the idea behind the current design is AFAIK that you use gitian *if* you are virtually sure that the build will pass, as a gitian build is/should be equivalent to a depends builds outside gitian
01:22 < wumpus> (of course, subtle issues with e.g. the VM setup can always interfere so it's a bit brittle...)
01:54 < GitHub18> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f7f44b1bdd15...d1e17ff6408c
01:54 < GitHub18> bitcoin/master 9bbe71b Wladimir J. van der Laan: net: Add and document network messages in protocol.h...
01:54 < GitHub18> bitcoin/master d1e17ff Wladimir J. van der Laan: Merge pull request #7181...
01:54 < GitHub31> [bitcoin] laanwj closed pull request #7181: net: Add and document network messages in protocol.h (master...2015_12_network_messages) https://github.com/bitcoin/bitcoin/pull/7181
02:19 < GitHub141> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/8fc174aae64882d43549ad57bece0c23805e567b
02:19 < GitHub141> bitcoin/0.12 8fc174a Wladimir J. van der Laan: net: Add and document network messages in protocol.h...
02:28 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
02:52  * Luke-Jr ponders if the cache ought to be a sshfs mount so it doesn't copy all 1 GB of files that don't get used every time
02:54 < Luke-Jr> hm, KVM can do a builtin SMB server for the host..
03:25 < wumpus> yea - if there is some built-in way to share filesystems in the virtualization solution, I think that makes more sense than using sshfs, which is slow
03:26 < wumpus> lxc can simply mount 'host' directories as well
03:26 < wumpus> so using a scratchpad instead of copying everything every time could work
03:28 < Luke-Jr> right
03:30 < wumpus> avoids both the ssh and copy overhead - but it's work, no one ever got around to implementing that, and testing all that
03:32 < wumpus> btw apparently marcofalke had already switched the key type to rsa with https://github.com/devrandom/gitian-builder/pull/107, I do think it should carry a clearer warning that now all the base vms have to be regenerated
03:33 < Luke-Jr> :x
03:33 < wumpus> although re: dependencies, arguably the copy overhead is minimal compared to the time it takes to build, or even prepare a VM for building (all this package upgrading..) so I'm not sure it's that much of a win in practice compared to the work
03:34 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
03:37 < Luke-Jr> maybe not, just annoying ;)
03:37 < Luke-Jr> perhaps I'll just change it to use rsync so the download-to-host step is quicker
03:39 < Luke-Jr> oh blah, we're on ancient Ubuntu
03:49 < wumpus> using rsync would already be nice
03:49 < wumpus> not to ancient to have rsync I suppose?
03:57 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.]
03:57 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
03:57 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Client Quit]
03:58 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
04:03 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Ping timeout: 272 seconds]
04:15  * jonasschnelli is a fan of rsync/rdiff and rdiff backup
04:33 < morcos> wumpus: 7156 looks like it has a lot of ACK's (remove cs_main from createrawtransaction)
04:34 < wumpus> morcos: thanks
04:47 < jonasschnelli> I agree. It's merge ready.
04:53 -!- BashCo [BashCo@gateway/vpn/mullvad/x-rtrwkirgxbfgwneu] has quit [Remote host closed the connection]
04:53 -!- BashCo [BashCo@gateway/vpn/mullvad/x-sxqdlhnhbkefwycx] has joined #bitcoin-core-dev
04:58 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has quit [Ping timeout: 245 seconds]
05:29 -!- BashCo [BashCo@gateway/vpn/mullvad/x-sxqdlhnhbkefwycx] has quit [Remote host closed the connection]
05:29 -!- BashCo [BashCo@gateway/vpn/mullvad/x-kqhfxqguocwbjhxf] has joined #bitcoin-core-dev
05:42 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
05:46 -!- JackH_ [~Jack@host-80-43-141-169.as13285.net] has joined #bitcoin-core-dev
05:48 -!- JackH [~Jack@host-80-43-143-143.as13285.net] has quit [Ping timeout: 272 seconds]
05:49 -!- corb [~Jack@host-80-43-140-204.as13285.net] has joined #bitcoin-core-dev
05:51 -!- JackH_ [~Jack@host-80-43-141-169.as13285.net] has quit [Ping timeout: 240 seconds]
05:56 < GitHub177> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d1e17ff6408c...9ee02cf564d1
05:56 < GitHub177> bitcoin/master 6e76587 Wladimir J. van der Laan: rpc: remove cs_main lock from `createrawtransaction`...
05:56 < GitHub177> bitcoin/master 9ee02cf Wladimir J. van der Laan: Merge pull request #7156...
05:56 < GitHub94> [bitcoin] laanwj closed pull request #7156: rpc: remove cs_main lock from `createrawtransaction` (master...2015_12_createrawtransaction_nolock) https://github.com/bitcoin/bitcoin/pull/7156
06:22 -!- Tera2342 [~Tera2342@171.5.147.64] has quit [Ping timeout: 250 seconds]
06:33 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
07:05 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev
07:06 -!- jcorgan [~jcorgan@ec2-54-67-38-167.us-west-1.compute.amazonaws.com] has joined #bitcoin-core-dev
07:06 -!- jcorgan [~jcorgan@ec2-54-67-38-167.us-west-1.compute.amazonaws.com] has quit [Changing host]
07:06 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev
07:27 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.]
07:27 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
07:32 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Ping timeout: 250 seconds]
07:36 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
07:40 -!- jtimon [~quassel@74.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
07:52 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
08:03 -!- bawong [~rich@c-50-184-106-81.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
08:07 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 240 seconds]
08:12 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.]
08:13 -!- bawong [~rich@c-50-184-106-81.hsd1.ca.comcast.net] has quit [Ping timeout: 250 seconds]
08:17 -!- bawong [~rich@c-50-184-106-81.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
08:17 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
08:22 -!- bawong [~rich@c-50-184-106-81.hsd1.ca.comcast.net] has quit [Ping timeout: 272 seconds]
08:24 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.]
08:32 -!- jamesob [~job_@50-201-192-119-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
08:38 < jamesob> anyone have suggestions for parts of core that are under-unittested?
08:42 < morcos> jamesob: AcceptToMemoryPool but its one of the more difficult thngs to test.
08:43 < jamesob> in terms of getting the necessary fixture context set up, or something else?
08:43 < morcos> I was going to rework miner_test.cpp at some point, b/c many of them were designed to make sure the mining code did not assume the mempool contained txs that couldn't be mined, but now the mining code does assume that
08:43 < jamesob> hah, I see
08:44 < morcos> yes, in terms of setup.  i think there is a test that uses ATMP, but does it on regtest.
08:44 < morcos> which isn't really the right thing for more general ATMP tests
08:44 < morcos> the miner_tests actually construct blocks that can be used on mainnet i think
08:44 < morcos> so maybe that should be abstracted out into a setup that other tests can use
08:45 < jamesob> ATMP?
08:45 < morcos> AcceptToMemoryPool
08:45 < jamesob> ah
08:45 < jamesob> (first cup of coffee has yet to make it down ;)
08:46 < jamesob> yeah, I'll take a look, see if I can grok. may PM you if I get any ideas.
08:46 < morcos> sure
09:05 -!- jouke [~jouke@unaffiliated/komkommer] has quit [Quit: Changing server]
09:18 -!- fkhan [weechat@gateway/vpn/mullvad/x-lkxmxpmacezohmyl] has quit [Ping timeout: 240 seconds]
09:32 -!- fkhan [weechat@gateway/vpn/mullvad/x-xmxxfxosszvgrmxi] has joined #bitcoin-core-dev
09:33 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
09:33 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
09:54 -!- jcorgan is now known as jcorgan|away
11:08 -!- larrysalibra [~larry@101.78.244.172] has joined #bitcoin-core-dev
11:09 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
11:09 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
11:15 < gmaxwell> wumpus: No, we shouldn't revert #4906 we should just move forward from it.
11:15 -!- larrysalibra [~larry@101.78.244.172] has quit [Read error: Connection reset by peer]
11:42 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
11:44 -!- jcorgan|away is now known as jcorgan
11:54 -!- fkhan [weechat@gateway/vpn/mullvad/x-xmxxfxosszvgrmxi] has quit [Ping timeout: 240 seconds]
11:55 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
12:03 -!- jamesob [~job_@50-201-192-119-static.hfc.comcastbusiness.net] has quit [Ping timeout: 256 seconds]
12:05 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Remote host closed the connection]
12:08 -!- fkhan [weechat@gateway/vpn/mullvad/x-qukxegzfdyrswsjt] has joined #bitcoin-core-dev
12:09 -!- tripleslash_a [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
12:10 -!- jamesob [~job_@50-201-192-119-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
12:11 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 256 seconds]
12:12 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Quit: .]
12:15 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
12:26 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
12:36 -!- tripleslash_a [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 256 seconds]
12:45 -!- corb [~Jack@host-80-43-140-204.as13285.net] has quit [Ping timeout: 240 seconds]
12:45 -!- raedah [~raedah@172.58.41.43] has joined #bitcoin-core-dev
12:47 -!- jamesob [~job_@50-201-192-119-static.hfc.comcastbusiness.net] has quit [Ping timeout: 256 seconds]
13:07 -!- fkhan [weechat@gateway/vpn/mullvad/x-qukxegzfdyrswsjt] has quit [Ping timeout: 240 seconds]
13:09 -!- jtimon [~quassel@74.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]
13:21 -!- fkhan [weechat@gateway/vpn/mullvad/x-lmiuaohbnwqaxiet] has joined #bitcoin-core-dev
13:41 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
13:43 -!- paulbernard [~paulberna@ec2-52-6-136-108.compute-1.amazonaws.com] has joined #bitcoin-core-dev
13:59 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
14:01 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
14:47 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
14:47 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
15:14 -!- bawong [~rich@c-50-184-106-81.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
15:27 -!- raedah [~raedah@172.58.41.43] has quit [Quit: Leaving]
15:27 < gmaxwell> I've been giving some though to bringing back the tiered fee behavior bitcoin had untul mid 2012. The earlier logic had a rate table where transactions were added in arrival order, with the required fee gradually going up as the non-fee-sorted candidate block became bigger. In 2012 it was changed to the sorting based selection on the basis that this was the rational behavior to miners, and the '
15:27 < gmaxwell> fullness' of a candidate block was pretty opaque to users.  
15:28 < gmaxwell> What the logic was was that up to half the target size, the ordinary fee behavior applied. above half the target the required fee was multiplied by target/(target-current). 
15:29 < gmaxwell> What we lost in that change is any backpressure at all, until the limit was met.  The belief that this was good for miners was mistaken in any case, since fees relative to orphan impact are small. 
15:31 < gmaxwell> And then the need to constantly keep bumping the soft limit to avoid that cliff from the system being poorly stabalized also meant that blocks found fast would glup down a pile of spamflood.
15:37 < gmaxwell> I think we've probably not given this enough thought due to paying too much attention to what short term rational miner behavior would be; when probably really optimizing miner behavior would already not be including most of the transactions today at current feerates.
15:42 < zookolaptop> Right. Bounded rationality. I'm a businessman, and if there are two sources of revenue, one of which gives 100X what the other one gives, then I would tend to say "FUCK that other one! Don't bother me. Don't spend your time thinking about that other one.".
15:43 < zookolaptop> 100X is correct, currently, right? 
15:45 -!- raedah [~raedah@172.58.41.43] has joined #bitcoin-core-dev
15:45 < zookolaptop> That's what I wrote on twitter the other day, on my way home from Hong Kong. https://twitter.com/zooko/status/674422815299231744
15:55 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has joined #bitcoin-core-dev
15:56 < gmaxwell> The other thing is that the rational marginal feerate needed to add an attitional transaction to a block actually goes down at the block gets bigger; not up.
15:58 < zookolaptop> Good point.
15:58 < gmaxwell> This is because the possion distributions of blocks, has an exponential distribution of interblock intervals, which has a slope that decreases with more delay.  Basically, if you're already screwed latency wise, the marginal harm of including another transaction is less.
16:00 < zookolaptop> Makes sense. Also I'll bet there are quantization effects and "economies of scale" more locally, too, e.g. bufferbloat.
16:00 < gmaxwell> well mining inequality of delay throws this all out.
16:01  * zookolaptop squints.
16:01 < zookolaptop> What's that?
16:03 < gmaxwell> zookolaptop: e.g. if a miner is a super majority hashpower they don't ever have to get orphaned; so there is little to harm in terms of orphaning to make blocks as big as they want.
16:03 < gmaxwell> In any case, formula for marginal feerate in order to overcome subsidy loss; there are an infinite number of tiny miners who all have the same constant and size sensitive delays is (41.6623*e^(((-0.00166649*size)/bytes_per_sec)-0.00166649*delay_sec))/bytes_per_sec    (this is just the derivative of the orphaning cost for a given size/delay/bandwidth assuming 600s blocks)
16:04 -!- amiller [~socrates1@unaffiliated/socrates1024] has quit [Quit: ZNC - http://znc.sourceforge.net]
16:07 < gmaxwell> (thats for btc per 1000 bytes, which is usually the unit we use for fees)
16:08 < gmaxwell> For 2.491s/90415 bytes/s which were the straum observed measurements; this function is nearly linear in the domain 0-1mb, 0.0004588 to 0.000450 BTC/kb.
16:09 < gmaxwell> so the irritating thing here is that the negative slope is opposite of what a stable control law needs here. So I think effort to make the behavior sensible needs to just abandon being rationally optimizing; at least for right now.
16:13 < zookolaptop> I don't know what that function looks like.
16:13 < zookolaptop> I can't graph that function in my head.
16:13 < zookolaptop> And see the slope you mean.
16:13 -!- ParadoxSpiral_ [~ParadoxSp@80.139.129.190] has quit [Quit: cya]
16:15 -!- bawong [~rich@c-50-184-106-81.hsd1.ca.comcast.net] has quit [Ping timeout: 272 seconds]
16:15 < zookolaptop> And I don't know about the straum observed measurements, but I'm very glad to hear there were empirical measurements,
16:15 < zookolaptop> and I conclude from theexample numbers--0.0004588 BTC/kb--that nobody cares about this. :-)
16:16 < zookolaptop> Because that's too little to care about.
16:16 -!- bitdevsnyc [~bitdevsny@cpe-158-222-198-108.nyc.res.rr.com] has joined #bitcoin-core-dev
16:17 < zookolaptop> Do you disagree?
16:18 < gmaxwell> over 0-1mb it looks like a straight line.   Overall it looks like e^(-x).  (starts out high, goes down)
16:18 < zookolaptop> I think my conclusion then is the same as yours: bounded rationality here, or at least "Zooko's estimation of likely behavior of near-future miners", is to ignore the fees.
16:18 < gmaxwell> zookolaptop: yes/no.  It's actually considerably higher than gees being paid right now. 
16:18 < zookolaptop> Ok.
16:19 < zookolaptop> Oh, it works out to about 0.45 BTC for a full 1 MB block?
16:20 -!- amiller [~socrates1@unaffiliated/socrates1024] has joined #bitcoin-core-dev
16:20 < gmaxwell> Yes.
16:20 < zookolaptop> That's 2% of current reward, instead of the 1% that I estimated from empirical measurements above.
16:20 < zookolaptop> So... I'm *fairly* sure that still most miners don't care? But then we get to the next reward halving, in which case this gets to be 4%?
16:21 < gmaxwell> Yes.
16:21 < zookolaptop> Hm.
16:21 < gmaxwell> I think the fact that miners haven't all gone and computed this themselves and set their minfee higher suggests we still don't _currently_ need to worry that much about short term rational behavior for most miners.
16:22 < zookolaptop> Right, and I my only modification to that point is to argue that not doing this is rational for them.
16:22 < zookolaptop> Because tweaking a config param in their system endangers their operations, which could suddenly cost them $30K/day if it goes wrong, 
16:23 < zookolaptop> and the best possible outcome they could get from the "rational" tweak you propose is, like, $50/day or so ?
16:23 < gmaxwell> And many other effects too.  Of course, all thats fragile, e.g. someone publishes another version.
16:23 < zookolaptop> And because whoever is focusing their attention on that tweaking should probably get to work and optimize what really matters: reducing costs so that more of the $30K/day revenue is margin instead of lost!
16:24 < zookolaptop> It's too bad you weren't in Hong Kong. The miners panel was awesome.
16:24 < zookolaptop> amiller: same to you!
16:25 < gmaxwell> zookolaptop: well thats part of the tradeoff I'm talking about. The reason that 0.0004etc is the lowest they really should accept is because lower than that increases the odds they lose the 25 BTC subsidy, by more than the fees gained.
16:25 < gmaxwell> In any case I brought that threshold amount as only a point that limiting ourself strictly to short term income maximizing behavior isn't necessary.
16:26 < zookolaptop> Um, isn't that an argument that tweaking this config could improve profit by *more* than $50/day ?
16:26 < zookolaptop> Okay, I accept your point.
16:27 < gmaxwell> And it's not good; because the current "sort by fees, take the target_size off the top"  encourages dumb behavior by the users:  You should gamble if the target is going to be met, pay very low amounts (just enough to get relayed) ... and then be shocked-shocked! when the target gets met and the system is operating in an totally different region of behavior.
16:28 < gmaxwell> esp since the random block finding makes the fullness at any instant pretty unpredictable.
16:29 < gmaxwell> and also undermines the utility of fee as an anti-spam, e.g. someone keeps a huge backlog of junk and any time some blocks are found in quick succession, miners are dipping into transactions that paid almost nothing.
16:31 < zookolaptop> Sounds reasonable.
16:31 < zookolaptop> So, under the assumptions laid out above, is there a nice simple alternative?
16:31 < zookolaptop> The goals would be: 1. not so bad for miners that they choose to diverge from it, in the short term
16:32 < zookolaptop> which as discussed should be easy to meet.
16:32 < zookolaptop> 2. Predictable behavior for users ?
16:33 < gmaxwell> So what bitcoin did pre-2012 was more reasonable; in the sense that it provided gradual back pressure, but it depended on future state and it was strangely order dependant.  (e.g. first txn into a block could go in with low fees, then higher paying things were excluded later).
16:35 < zookolaptop> *nod*
16:36 < gmaxwell> perhaps something as simple as having a target-size; sorting blocks by their feerate, and keeping a moving average of the rate at the target size; and using some function of that as a threshold for mining.
16:38 < gmaxwell> so even if there is a fast run of blocks, it won't mine a bunch of spam... and if it takes a long time between blocks, it'll just produce a larger block.
16:39 < zookolaptop> Target blocksize?
16:40 < zookolaptop> Moving average of fees from recent blocks ?
17:02 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer]
17:03 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
17:05 -!- bitdevsn_ [bitdevsnyc@gateway/vpn/mullvad/x-woeyuoaxsebceexn] has joined #bitcoin-core-dev
17:07 -!- bitdevsnyc [~bitdevsny@cpe-158-222-198-108.nyc.res.rr.com] has quit [Ping timeout: 240 seconds]
17:13 -!- Tera2342 [~Tera2342@171.5.159.101] has joined #bitcoin-core-dev
17:24 -!- paulbernard [~paulberna@ec2-52-6-136-108.compute-1.amazonaws.com] has left #bitcoin-core-dev ["Leaving"]
17:49 -!- zookolaptop [~user@2601:281:8001:26aa:6878:6b87:8777:e14a] has quit [Remote host closed the connection]
17:52 -!- zookolaptop [~user@2601:281:8001:26aa:6d4c:c7eb:6a6a:6504] has joined #bitcoin-core-dev
18:08 -!- zookolaptop [~user@2601:281:8001:26aa:6d4c:c7eb:6a6a:6504] has quit [Ping timeout: 250 seconds]
18:11 < GitHub130> [bitcoin] accraze opened pull request #7200: Checks for null data transaction before issuing error to debug.log (master...null-tx-debug) https://github.com/bitcoin/bitcoin/pull/7200
18:11 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-jgxgogaylkjucbjk] has quit [Quit: Connection closed for inactivity]
18:12 -!- bitdevsnyc [~bitdevsny@cpe-158-222-198-108.nyc.res.rr.com] has joined #bitcoin-core-dev
18:15 -!- instagibbs [~instagibb@100.15.115.26] has quit [Ping timeout: 246 seconds]
18:16 -!- bitdevsn_ [bitdevsnyc@gateway/vpn/mullvad/x-woeyuoaxsebceexn] has quit [Ping timeout: 272 seconds]
18:18 -!- zookolaptop [~user@2601:281:8001:26aa:6d4c:c7eb:6a6a:6504] has joined #bitcoin-core-dev
18:24 -!- Tera2342 [~Tera2342@171.5.159.101] has quit [Read error: Connection reset by peer]
18:34 -!- zookolaptop [~user@2601:281:8001:26aa:6d4c:c7eb:6a6a:6504] has quit [Ping timeout: 250 seconds]
18:34 -!- raedah [~raedah@172.58.41.43] has quit [Ping timeout: 250 seconds]
18:37 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
18:50 -!- jannes [~jannes@178.132.211.90] has quit [Ping timeout: 256 seconds]
18:58 -!- bitdevsnyc [~bitdevsny@cpe-158-222-198-108.nyc.res.rr.com] has quit [Remote host closed the connection]
19:19 -!- bawong [~rich@c-50-184-106-81.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
19:24 -!- jl2012 [~jl2012@119246245241.ctinets.com] has quit [Read error: Connection reset by peer]
19:33 < btcdrak> gmaxwell: that's a pretty interesting conversation regarding fees.
19:49 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
20:11 -!- jl2012 [~jl2012@unaffiliated/jl2012] has joined #bitcoin-core-dev
20:29 < Luke-Jr> gmaxwell: supporting that has been one of my goals with trying to rework the mining code (but as one of many possible options)
21:10 -!- spqr [~spqr@2601:406:8002:5291:1107:ecc8:cf15:38b9] has joined #bitcoin-core-dev
21:10 < spqr> hello
21:41 -!- spqr [~spqr@2601:406:8002:5291:1107:ecc8:cf15:38b9] has quit [Ping timeout: 240 seconds]
21:59 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has quit [Quit: Later.]
23:36 -!- bawong [~rich@c-50-184-106-81.hsd1.ca.comcast.net] has quit [Ping timeout: 256 seconds]
23:53 -!- jcorgan is now known as jcorgan|away