1 2015-11-10 00:42:11 <gmaxwell> 0c14f2fd394caa357c79f023fff434032e19f7be6a17668e0b00af3ff9444df3
 2 2015-11-10 02:37:56 <tulip> lclc: no, it uses a more complex solver.
 3 2015-11-10 02:43:26 <otoburb> bsm1175321: 25 spots available, but 85 going? is the venue big enough?
 4 2015-11-10 07:32:04 <sturles> When mempool trimming has started, will mempoolminfee ever go back to zero, or will only a restart fix that?  Mempool trimming is completely broken for free transactions.
 5 2015-11-10 07:43:14 <phantomcircuit> sturles, high priority will not get you free transactions pretty soon anyways
 6 2015-11-10 07:51:08 <sturles> Why?  It works fine as long as the priority is high enough.
 7 2015-11-10 07:51:47 <sturles> Some pools even reserve half the block for high priority transactions.
 8 2015-11-10 07:53:49 <dcousens> I often forget how awesome unix pipes are
 9 2015-11-10 07:54:17 <dcousens> Just saved my self writing a tonne of stream code for analyzing some blk data by just using `cat blk* | ./analyze` instead
10 2015-11-10 07:54:37 <sturles> phantomcircuit: Try running this with a non-trimmed mempool, and see how it changes when a block is found: watch -n 60 "bitcoin-cli getrawmempool true | awk '{if (/currentpriority/) pri = \$2; if (/descendantfees/) fee = \$2; if (/\]/) pf[pri] = fee;}END{for (p in pf) if(pf[p] == 0) print p;}' | sort -n | tail -n 40"
11 2015-11-10 09:01:33 <phantomcircuit> sturles, there's really no useful way to do the mempool limiting unless it's fee based only
12 2015-11-10 09:08:19 <sturles> Of course there is.
13 2015-11-10 09:08:29 <sturles> You could make it priority + fee based.
14 2015-11-10 09:09:05 <sturles> Like it is now, Bitcoin Core will trim away transactions which will be included in the next block if mining with the default settings.
15 2015-11-10 09:09:47 <sturles> The current version prioritize spam.
16 2015-11-10 09:10:35 <sturles> Low fee high priority less spammy transactions will get evicted before paying spam.  Which is ufortunate.
17 2015-11-10 09:56:18 <phantomcircuit> sturles, the current algorithm is hugely slow and inefficient
18 2015-11-10 10:03:09 <sturles> The current fee based algorithm?
19 2015-11-10 10:03:56 <sturles> Should probably replace it then.
20 2015-11-10 10:05:39 <phantomcircuit> sturles, no... the current released fee + priority based one
21 2015-11-10 10:05:48 <phantomcircuit> there's basically no reasonable way to implement both
22 2015-11-10 10:05:58 <phantomcircuit> as priority is recalculated for each new block
23 2015-11-10 10:07:01 <phantomcircuit> the algorithm in master is actually very fast
24 2015-11-10 10:07:19 <sturles> Ehm.  The current mempool trimming is 100% fee based.  Priority is not taken into account.  It will treat spam and other transaction equally based on fee alone.
25 2015-11-10 10:07:46 <sturles> See e.g. https://github.com/bitcoin/bitcoin/issues/6972
26 2015-11-10 10:08:02 <phantomcircuit> sturles, s/current/released/ i guess?
27 2015-11-10 10:08:19 <phantomcircuit> the entire concept of priority is flawed
28 2015-11-10 10:08:40 <sturles> Only if yur goal is to promote spam.
29 2015-11-10 10:08:43 <phantomcircuit> the security of the system is based entirely on miners acting in their own economic best interest
30 2015-11-10 10:08:52 <phantomcircuit> priority is the opposite of that
31 2015-11-10 10:08:59 <dcousens> sturles: only if you align yourself with the idea that the monetary incentive is the only one that counts
32 2015-11-10 10:09:28 <dcousens> I'd argue miners could align with a priority for a network stability based interest, however, that is entirely altruistic
33 2015-11-10 10:09:32 <sturles> Nope.  It should be in the miners best interest to allow normal transactions through and delay spam.
34 2015-11-10 10:09:57 <dcousens> sturles: why?
35 2015-11-10 10:10:24 <sturles> It is in no miners interest to prioritize spam over normal usage.  Because the only spammers will use bitcoin, and their block reward will become worthless.
36 2015-11-10 10:10:43 <dcousens> sturles: right, altruistic
37 2015-11-10 10:11:19 <sturles> Relying on fee alone is tragedy of the commons.
38 2015-11-10 10:11:41 <sturles> Which is why most miners don't.
39 2015-11-10 10:12:50 <sturles> Most miners will gladly offer 0.05% of their possible income to make regular transactions work better.
40 2015-11-10 10:13:32 <sturles> Because smoother operation lead to better adoption which lead to better income.
41 2015-11-10 10:18:26 <evoskuil> Fee reliance is not a commons tragedy. There is no applicable commons metaphor to bitcoin, or any other free market.
42 2015-11-10 10:18:48 <sturles> Compare the total block reward including fees for an average block mined by e.g. Bitminter (reserves 50% for high priority tx) to one of the Chineese pools which reserve very little.  See if there is any difference at all.
43 2015-11-10 10:19:20 <sturles> There is basically no economic incentive in promoting paid spam over high priority transactions.
44 2015-11-10 10:19:40 <sturles> Not even if your horizon is just one block ahead.
45 2015-11-10 10:19:49 <evoskuil> if it's paid its not spam, it's money
46 2015-11-10 10:22:04 <sturles> By what definition?  Wikipedia says you are wrong.
47 2015-11-10 10:22:20 <sturles> If I pay someone to send spam for me, it is still spam.
48 2015-11-10 10:24:04 <evoskuil> Says who, the spam police?
49 2015-11-10 10:25:37 <sturles> The dictionary.  Spam isn't illegal, just asocial.
50 2015-11-10 10:26:05 <evoskuil> Well then let's set up a red list and block it all.
51 2015-11-10 10:26:52 <sturles> evoskuil: Please do if it will take your mind of this absolutely pointless quarreling.
52 2015-11-10 10:29:00 <dcousens> sturles: other than high velocity money, what is your definition of spam, if it isn't paid for?
53 2015-11-10 10:29:05 <dcousens> if it is paid for*
54 2015-11-10 10:30:29 <sturles> See Wikipedia.
55 2015-11-10 10:30:50 <sturles> I don't have my own definition of spam.
56 2015-11-10 10:40:47 <phantomcircuit> sturles, just because fees are a small percent of block reward today does not mean they will be tomorrow
57 2015-11-10 10:43:48 <sturles> If you by "tomorrow" mean in ten years, we may agree.
58 2015-11-10 10:45:03 <sturles> It is not that fees in general is a small percentage, but when you start including the long tail based on fees alone, you gain nothing compared to including based on priority.
59 2015-11-10 10:46:43 <sturles> The highest paying transaction makes up about 1% of the total block reward, but after the first few kB of high paying transactions the fees are so low it makes no sense to filter based on them.
60 2015-11-10 10:53:24 <evoskuil> So... maybe blocks are too big :)
61 2015-11-10 10:57:11 <evoskuil> But I suppose that will take care of itself in ten years.
62 2015-11-10 11:02:27 <sturles> Yes, blocks are much larger than required today.
63 2015-11-10 11:10:22 <evoskuil> Good thing we have the block reward. Of course miners can mine empty blocks, which sort of counteracts the effect of blocks being too large.
64 2015-11-10 15:37:24 <bsm1175321> otoburb: the venue is big enough.  Usually only about half of those who sign up actually show up.
65 2015-11-10 16:30:31 <jgarzik> If anyone here is looking for a job hacking on open source Bitcoin Core C/C++, let me know...   jeff@bloq.com
66 2015-11-10 17:27:09 <instagibbs> Bloqstream? :O
67 2015-11-10 19:00:04 <Kireji> is there a denial of service possible with bitcoin core on ubuntu 14.04 that would cause the machine to hang?  over the last few weeks I've had a machine hang running a full node, and with a long series of turning services on and off, it appears it the bitcoin daemon may be to blame.  running 0.11.1 on default port, default conf, kernel 3.13.0-67-generic
68 2015-11-10 19:03:36 <jtimon> wumpus: ping https://github.com/bitcoin/bitcoin/pull/6982
69 2015-11-10 19:05:39 <jgarzik> Kireji, lately bitcoind has been using a lot of memory, several gigabytes.
70 2015-11-10 19:05:50 <jgarzik> Kireji, There is a possibility you're seeing that.
71 2015-11-10 19:06:27 <buZz> Kireji: did you monitor dmesg / rest of logs around these crashes?
72 2015-11-10 19:07:12 <buZz> Kireji: also have you tried running memtest86 on the machine while not running linux?
73 2015-11-10 20:30:56 <weex> can anyone help with a bitcoin script question for a multisig redeem script? https://bitcointalk.org/index.php?topic=1231148.msg12941124#msg12941124
74 2015-11-10 20:32:06 <weex> someone's trying to create a patch for coinb.in and has a question on whether an OP_DROP is necessary for a A+(B or C) type of multisig address
75 2015-11-10 21:31:17 <Kireji> buZz: jgarzik: this was on limited memory machine.  that could do it.  actively monitorring logs, nothgin good.  trying to increase logging verbosity across system.  it's a remote VM, so memtest not really an option.  thank you
76 2015-11-10 21:32:57 <buZz> welcome