1 2015-11-12 00:21:31 <bkukowski> is artforz still around?
  2 2015-11-12 00:21:45 <bkukowski> I haven't been here in a while
  3 2015-11-12 02:40:55 <stiell> Are bare multisig outputs still considered standard? Has e.g. 1-of-2 or 2-of-3 been considered for stealth-address transactions, where one of the keys is "fake" and used for deriving the shared secret?
  4 2015-11-12 02:43:05 <gmaxwell> that would only make it less efficient and not really solve any of the problems with it. (still trivially distinguishable, still high overhead, still not efficiently scanable, still has privacy problems in the sender wallet)
  5 2015-11-12 03:09:15 <rusty> Hmm, does bitcoind prune UTXOs which touch a wallet address, or are they preserved so you can always extract history?
  6 2015-11-12 04:24:14 <gmaxwell> rusty: the wallet itself keeps its own history.
  7 2015-11-12 04:24:53 <rusty> gmaxwell: right... seems like I should be polling on listsinceblock, *except* that doesn't show unconfirmed txs.
  8 2015-11-12 04:36:35 <phantomcircuit> rusty, poll on listtransactions and just have it return lots of them :)
  9 2015-11-12 04:37:49 <rusty> phantomcircuit: it was never clear to me that listtransactions was in order independent of reorgs.
 10 2015-11-12 04:38:27 <rusty> phantomcircuit: thus, I figure the only way to use it is with a count of bignum, and weed out yourself.
 11 2015-11-12 04:39:43 <rusty> Since I really want "tell me about any tx which touches this output", it's a bit awkward.
 12 2015-11-12 04:40:48 <CodeShark> rusty: what are you trying to do?
 13 2015-11-12 04:40:58 <rusty> CodeShark: hi!
 14 2015-11-12 04:41:01 <CodeShark> hello :)
 15 2015-11-12 04:41:51 <rusty> CodeShark: lightning needs to know various things.  When a tx reaches a certain depth (and later, if that changes due to reorg).  Whenever any tx spending a certain output appears.
 16 2015-11-12 04:42:32 <CodeShark> ah, yes...the need for this actually prompted much of my own projects - I've got a skeleton for a notification system that allows you to subscribe to such events
 17 2015-11-12 04:42:54 <rusty> Yeah, I'm hoping to abstract it away, just want something "working" for the prototype.
 18 2015-11-12 04:43:05 <CodeShark> trying to do this with the bitcoin core wallet RPC is, how shall we say...painful ;)
 19 2015-11-12 04:45:15 <CodeShark> it's fairly simple to do it live (just filtering tx and block relays, only need state for depth)
 20 2015-11-12 04:45:39 <CodeShark> but you'll probably need a queue in case you disconnect, etc...
 21 2015-11-12 04:47:10 <phantomcircuit> rusty, oh.... yeah that's not fun :P
 22 2015-11-12 04:48:26 <CodeShark> I guess you can poll the RPC for the sake of prototyping
 23 2015-11-12 04:49:18 <rusty> CodeShark: yep, that's the plan..
 24 2015-11-12 04:52:54 <CodeShark> I've got a system that does this for a particular m-of-n account structure, but I'm currently working on extending it to a broader set of cases
 25 2015-11-12 04:53:30 <CodeShark> we probably want to allow for more general script templates
 26 2015-11-12 04:54:23 <CodeShark> although if everything is p2sh, we can just use the redeemscript hash for all filtering
 27 2015-11-12 04:56:43 <CodeShark> rusty, you can always load a filter with the txouts you're interested in and sync blocks from a given height
 28 2015-11-12 04:56:56 <CodeShark> https://github.com/ciphrex/mSIGNA/blob/master/deps/CoinQ/examples/peer/src/main.cpp
 29 2015-11-12 05:27:33 <Jokergod> Hi, how are all ?
 30 2015-11-12 08:51:08 <jtoomim> is anyone else having trouble mining on testnet3?
 31 2015-11-12 08:51:57 <jtoomim> it appears to me that there might be a bug in PoW somewhere with massive reorgs, or something like that
 32 2015-11-12 08:52:21 <jtoomim> i haven't been able to mine since around the time the v4 chain overtook the v3 chain in PoW
 33 2015-11-12 08:53:01 <jtoomim> CPU mining fails silently, and ASIC mining via p2pool returns this:
 34 2015-11-12 08:53:06 <jtoomim> 2015-11-12 07:29:07.848005 ERROR: CheckProofOfWork(): hash doesn't match nBits
 35 2015-11-12 08:53:06 <jtoomim> 2015-11-12 07:29:07.848061 ERROR: CheckBlockHeader(): proof of work failed
 36 2015-11-12 08:53:06 <jtoomim> 2015-11-12 07:29:07.848113 ERROR: ProcessNewBlock: CheckBlock FAILED
 37 2015-11-12 08:54:43 <jtoomim> ASIC mining via ckpool fails silently as well
 38 2015-11-12 09:00:57 <gmaxwell> jtoomim: bitcoin core seems to be running fine.
 39 2015-11-12 09:01:20 <jtoomim> which version of core?
 40 2015-11-12 09:01:34 <jtoomim> i tried 0.9.2, since it was on one of my machines, and i had the same issue
 41 2015-11-12 09:02:00 <jtoomim> it might be a corrupted blockchain
 42 2015-11-12 09:02:38 <jtoomim> but it's a strange issue
 43 2015-11-12 09:02:46 <gmaxwell> 0.9.2 is very old and not fully compatible with the enforced on testnet by more recent software.
 44 2015-11-12 09:03:04 <jtoomim> my nodes are all following the v4 chain
 45 2015-11-12 09:03:11 <jtoomim> one is at 603158 right now
 46 2015-11-12 09:03:47 <jtoomim> i've also got a 11.1 node which i think had exclusive control over a blockchain copy, though it wasn't running continuously
 47 2015-11-12 09:03:51 <jtoomim> and it seems to be having the same issue
 48 2015-11-12 09:04:14 <jtoomim> 0.11.1, sorry
 49 2015-11-12 09:04:23 <jtoomim> gmaxwell, which version are you using?
 50 2015-11-12 09:05:20 <gmaxwell> 0.11.2 and master.
 51 2015-11-12 09:06:05 <jtoomim> is 11.2 v4?
 52 2015-11-12 09:07:00 <jtoomim> yes, it is
 53 2015-11-12 09:07:20 <gmaxwell> block version numbers are not directly coupled to software versions... v4 and greater signals CLTV enforcement. 0.11.2, 0.10.4, and git master are CLTV supporting versions of bitcoin core.
 54 2015-11-12 09:07:49 <jtoomim> i suspect that BIP65 may be implicated in this
 55 2015-11-12 09:08:14 <jtoomim> as i mentioned before, the issue appeared around the time that the v4 fork overtook the v3 and BIP101 forks
 56 2015-11-12 09:08:33 <gmaxwell> dubious.
 57 2015-11-12 09:08:44 <jtoomim> i hope i'm hallucinating
 58 2015-11-12 09:09:00 <gmaxwell> You're not even running software that has BIP65 (or BIP66 for that matter.)
 59 2015-11-12 09:09:01 <jtoomim> it would be nice if someone else were to test a v3 version
 60 2015-11-12 09:09:10 <jtoomim> i'm running 0.11.1
 61 2015-11-12 09:09:15 <jtoomim> as well as 0.9.2
 62 2015-11-12 09:09:23 <jtoomim> as well as XT 0.11B and C and D
 63 2015-11-12 09:09:34 <jtoomim> D = master, sorry
 64 2015-11-12 09:09:55 <jtoomim> the only block version i'm not running is a BIP65 one
 65 2015-11-12 09:09:56 <gmaxwell> You're failing to understand my point. Your issue is local; and cannot be caused by software you do not have.
 66 2015-11-12 09:10:19 <jtoomim> that's valid
 67 2015-11-12 09:10:28 <gmaxwell> Your own node is rejecting the work you are giving it because it believes it does not pass the difficulty check (for whatever reason)
 68 2015-11-12 09:10:31 <jtoomim> there may be a bug that was triggered by the reorg
 69 2015-11-12 09:11:11 <jtoomim> i'll try rebuilding the chain to see if that helps
 70 2015-11-12 09:13:11 <jtoomim> i'll probably fall asleep before the rebuild is done
 71 2015-11-12 09:13:24 <jtoomim> s/rebuild/reindex/g
 72 2015-11-12 09:14:54 <jtoomim> anyway, i just thought i should let you guys know, since Core at least two Core versions were also affected in my testing
 73 2015-11-12 09:24:20 <drazisil> does anyone happen to have json examples of stratum chatter between a miner and p2pool?
 74 2015-11-12 09:32:49 <jtoomim> use tcpdump
 75 2015-11-12 09:36:15 <drazisil> jtoomim: thank you
 76 2015-11-12 10:03:29 <phantomcircuit> jtoomim, there's no bug there
 77 2015-11-12 10:49:56 <oleganza> Hi there! I'd like to understand some security aspect of OP_CHECKSIG. It needs to place subscript (i.e. output script in absence of OP_CODESEPARATOR) in the txinput to compute the SignatureHash. My question is: what purpose does it have? If it was leaving all sigscripts empty, *including* the input currently being signed/verified, wouldn't it all work the same way?
 78 2015-11-12 10:52:15 <gmaxwell> yes, because the txin commits to the scriptpubkey, although its a politeness for hardware wallets, in that they can know they are signing for the scriptpubkey they think they're signing for without having to send them the whole input transaction. Sadly, it doesn't include the amount, which is also critical to check.
 79 2015-11-12 10:52:17 <oleganza> There could be a use case in 2009 when CODESEPARATOR was actually used, but today it seems to be a useless behaviour left for compatibility reasons.
 80 2015-11-12 10:52:47 <oleganza> gmaxwell: aha, that's a fair point
 81 2015-11-12 10:52:53 <gmaxwell> With OP_CODESEPARATOR's apparent original intent it would have been more useful.
 82 2015-11-12 10:52:57 <oleganza> but without amount it seems rather useless
 83 2015-11-12 10:53:56 <oleganza> So if hardware wallet needs parent tx anyway to check the amount, then this subscript inclusion is otherwise useless?
 84 2015-11-12 10:54:18 <oleganza> I mean today, in 2015 when we don't need codeseparator
 85 2015-11-12 10:55:30 <oleganza> gmaxwell: thanks for your comment
 86 2015-11-12 10:55:33 <rubensayshi> there are quite a few people actually doing that without knowledge of the parent tx
 87 2015-11-12 10:55:51 <rubensayshi> because of a limited amount of trust in w/e is providing the unsigned TX
 88 2015-11-12 10:56:24 <gmaxwell> rubensayshi: there are _lots_ of people using "HSM"s that sign anything presented to them with no checking at all.
 89 2015-11-12 10:56:43 <oleganza> which defeats the whole purpose of having HSM in the first place
 90 2015-11-12 10:56:44 <gmaxwell> such moves provide virtually no security, but sound good when you rattle them off to customers. :-/
 91 2015-11-12 10:56:52 <rubensayshi> hehe
 92 2015-11-12 11:02:47 <wumpus> well they need to compromise you persistently instead of just and and nab the key. I can see how that's - somewhat- helpful for, say, certificate authorities, because there is an audit trail of every use. But not for bitcoin, no, where you can sign away everything with one transaction.
 93 2015-11-12 11:04:40 <gmaxwell> in bitcoin at least you cannot sign for future transactions paid to that key, unless you keep the compromise going.
 94 2015-11-12 11:04:48 <gmaxwell> but thats about the only advantage.
 95 2015-11-12 11:05:32 <gmaxwell> HSM vendors are _remarkably_ resistant to having any support for customer provided business logic (and also claim that no one wants it).
 96 2015-11-12 11:49:59 <wumpus> well let's say that, escaping the limits of human psychology and possibly physics, you made some piece of hw+sw finally safe, and, would you let pesky user software on it? :-)
 97 2015-11-12 11:51:05 <gmaxwell> true, users seem to be the root of all problems. kill all the users!
 98 2015-11-12 11:51:12 <wumpus> yeah!
 99 2015-11-12 11:51:55 <gmaxwell> you'd think they'd still have some competative advantage by building in some super sandbox (I don't even care if its pretty slow) but it seems most people don't ask for this and are perfectly happy with the black box that signs anything. :)
100 2015-11-12 11:56:22 <wumpus> sure, I agree, at some point it's just "a computer with carefully controlled interface, tamper protection, and extensive logging", and I'm sure there is a market for that
101 2015-11-12 12:30:35 <jonasschnelli> Oh. I missed the hardware wallet discussion.
102 2015-11-12 12:32:16 <jonasschnelli> <oleganza>
103 2015-11-12 12:33:55 <jonasschnelli> and i agree with wumpus: hw-wallet not automatically increase the users security. But the have the potential to sign data in a very secure way, if done right.
104 2015-11-12 12:34:17 <jonasschnelli> We all know that keeping private keys on a standard computer is by default a bad idea.
105 2015-11-12 12:35:23 <jonasschnelli> As wumpus mentioned, hardware wallets are tiny computers that are trying to reduce I/O to a minimum
106 2015-11-12 12:45:43 <wumpus> "We all know that keeping private keys on a standard computer is by default a bad idea" yep. too much malware that just nabs wallet.dat (as well as does keylogging). Anything that makes attacks harder and more expensive is good. gmaxwell's point was that HSMs that just dumbly sign everything withoout user confirmation or checking are not very useful for bitcoin.
107 2015-11-12 12:46:07 <jonasschnelli> Right. This is the hard part.
108 2015-11-12 12:47:16 <jonasschnelli> The software i'm working on, will allow to 2FA-lock the hardware wallet. Transactions can only be signed by entering a second factor, retrievable over a smartphone by verifing the data to sign.
109 2015-11-12 12:47:52 <jonasschnelli> The hardware wallet and the smartphone need to be paired once over a ECDH pattern.
110 2015-11-12 12:49:12 <jonasschnelli> An attacker would require to MITM your PC, forge a transaction, break your ECDH/AES256 or additionally root access your smartphone.
111 2015-11-12 12:49:34 <jonasschnelli> All possible but much harder than hacking/stealing something like "wallet.dat".
112 2015-11-12 12:54:38 <wumpus> right - most automated attacks will hit either your PC or your smartphone, not both. Targeted attacks might, but it's at least a higher bar.
113 2015-11-12 12:57:09 <jonasschnelli> Right, and you can always increase security by adding another multisig participant (another hardware wallet [maybe from another vendor], or another smartphone, etc.).
114 2015-11-12 12:57:24 <jonasschnelli> Just make sure you still know which smartphone participates in which wallet...
115 2015-11-12 12:57:45 <jonasschnelli> and the risk of missing or losing a backup gets higher...
116 2015-11-12 12:58:15 <wumpus> that's the other risk that has to be balanced, risk of loss
117 2015-11-12 14:07:38 <Exxpre> hello guys, i am working on developing a wallet.
118 2015-11-12 14:07:57 <Exxpre> looking for help on storing users wallet structure
119 2015-11-12 14:08:11 <jonasschnelli> Exxpre: sure. what db/format are you using right now?
120 2015-11-12 14:08:28 <jonasschnelli> what language your are working with?
121 2015-11-12 16:36:26 <jtoomim> jonasschnelli gmaxwell probably user error then. thanks for checking.
122 2015-11-12 16:36:39 <jtoomim> oops phantomcircuit not jonash
123 2015-11-12 16:51:20 <Abstrct> Hi folks, I'm looking to run an alpha test for a project I'm working on but I want to be able to give my testers some testnet coins. Is there somewhere (other than setting up miners) I can get something more substantial than whats available through a faucet?
124 2015-11-12 16:52:26 <sturles> Asking here is a good start.  I think e.g. phantomcircuit has lots of testnetcoins.
125 2015-11-12 16:56:00 <Abstrct> Great! Nice to hear I'm on the right track.
126 2015-11-12 16:56:44 <phantomcircuit> Abstrct, how many you want??
127 2015-11-12 16:56:59 <phantomcircuit> no but seriously https://tpfaucet.appspot.com/
128 2015-11-12 16:57:01 <phantomcircuit> that one works
129 2015-11-12 16:58:18 <Abstrct> I would like to be able to give each tester at least 5, with between 5-10 people testing.
130 2015-11-12 16:58:58 <Abstrct> I have managed to grab some off of faucets but I also don't want to drain every faucet out there as that seems like a jerk move
131 2015-11-12 17:01:50 <phantomcircuit> Abstrct, i regularly refill that faucet
132 2015-11-12 17:03:15 <Abstrct> Alright, well I will just hit it for a couple days then. Thanks for keeping it filled :)
133 2015-11-12 17:06:55 <Abstrct> Thanks for the quick replies - have a good one
134 2015-11-12 19:00:30 <gmaxwell> Meeting?
135 2015-11-12 19:00:32 <petertodd> yup
136 2015-11-12 19:00:54 <jtimon> here
137 2015-11-12 19:01:03 <jonasschnelli> Yes
138 2015-11-12 19:01:10 <morcos> Suggested topic: What to do about priority for 0.12?  (besides cry)
139 2015-11-12 19:01:24 <wumpus> #meetingstart
140 2015-11-12 19:01:42 <lightningbot> Meeting started Thu Nov 12 19:01:42 2015 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
141 2015-11-12 19:01:42 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
142 2015-11-12 19:01:42 <wumpus> #startmeeting
143 2015-11-12 19:01:43 <BlueMatt> morcos: that
144 2015-11-12 19:02:02 <wumpus> #topic What to do about priority for 0.12?  (besides cry)
145 2015-11-12 19:02:35 <petertodd> morcos: ditch it for now IMO, and work on a more general mechanism to get arbitrary txs propagated (perhaps priority, perhaps hashcash, maybe both!)
146 2015-11-12 19:03:01 <BlueMatt> remove priority entirely
147 2015-11-12 19:03:03 <phantomcircuit> wumpus, the wallet needs to be fixed... that is all
148 2015-11-12 19:03:07 <morcos> So as I commented on sdaftuars #6992, what I care most about is having 0.12 have a nice consistent state
149 2015-11-12 19:03:16 <BlueMatt> yes, remove all priority is consistent :)
150 2015-11-12 19:03:21 <morcos> semi-supporting priority in a broken manner is bad
151 2015-11-12 19:03:41 <jtimon> ack on removing enterely, it will be more disruptive the longer we wait
152 2015-11-12 19:03:45 <BlueMatt> we still have the fee adjustment RPC for miners that need to adjust fees, and we can (maybe) use that later to add our own default adjustments if people cry too much, though I'd rather not
153 2015-11-12 19:03:46 <sdaftuar> well i think pulling priority entirely without ever having warned is too abrupt
154 2015-11-12 19:03:52 <morcos> BlueMatt: I'm ok with that if its politically feasible, but seems like we should have communicated on the -dev list a long time ago and would maybe have gotten some pushback
155 2015-11-12 19:03:56 <jtimon> and we will remove it eventually
156 2015-11-12 19:03:59 <sipa> sdaftuar: agree
157 2015-11-12 19:04:18 <petertodd> morcos: not that many people use priority, particularly since even right now it's not very reliable and hard to calculate
158 2015-11-12 19:04:27 <sdaftuar> i proposed a staggered approach in #6992 -- let's let people know we're deprecating, and then plan to pull it in the next release
159 2015-11-12 19:04:31 <BlueMatt> the only people who use priority are devs, pretty much
160 2015-11-12 19:04:36 <BlueMatt> I dont think we need much time to announce
161 2015-11-12 19:04:37 <sdaftuar> and in 0.12 we can default the blockprioritysize to 0
162 2015-11-12 19:05:05 <petertodd> sdaftuar: well, the upgrade path is itself a staggered approach - not everyone will got to v0.12.0 instantly, and you don't need 100% to propagate reasonably well
163 2015-11-12 19:05:08 <phantomcircuit> we've made the mistake in the past of failing to communicate well that something will not work long term
164 2015-11-12 19:05:13 <petertodd> phantomcircuit: +1
165 2015-11-12 19:05:13 <phantomcircuit> lets not make that mistake again
166 2015-11-12 19:05:27 <morcos> yes, but that starts with communicate
167 2015-11-12 19:05:37 <petertodd> sdaftuar: also, XT will likely keep priority, which gives people an option
168 2015-11-12 19:06:00 <phantomcircuit> morcos, "this is now deprecated" afaict no wallet outside of bitcoin core implements priority calculations
169 2015-11-12 19:06:05 <CodeShark> not really an option if you can't pick and choose granularly :)
170 2015-11-12 19:06:11 <jtimon> action item communicate it on the ml?
171 2015-11-12 19:06:24 <gavinandresen> What’s the plan to mitigate the “spend money on fees, crowd out everybody else’s transactions” attack if priority goes away?
172 2015-11-12 19:06:46 <BlueMatt> gavinandresen: that is bitcoin
173 2015-11-12 19:06:48 <phantomcircuit> gavinandresen, there isn't a plan because that's a fundamental property of the system
174 2015-11-12 19:07:06 <phantomcircuit> if someone wants to blow wads of cash on trying to break things they can buy miners just as easily
175 2015-11-12 19:07:09 <petertodd> gavinandresen: those attacks are horribly expensive...
176 2015-11-12 19:07:39 <petertodd> phantomcircuit: exactly - as fees pay more of miners' incomes, those attacks become as expensive as just 51% attacking the network anyway
177 2015-11-12 19:07:42 <gavinandresen> petertodd: really?  I thought the latest spam attack showed it was fairly chieap....
178 2015-11-12 19:07:59 <CodeShark> about all we can do is make it expensive - but economics dictates that sufficiently well-funded adversaries can attack the network
179 2015-11-12 19:07:59 <petertodd> gavinandresen: yes, but it was also ineffective at stopping normal users from sending txs
180 2015-11-12 19:08:05 <morcos> gavinandresen: tx fees to get mined quickly never went up that high
181 2015-11-12 19:08:09 <petertodd> gavinandresen: that's why we have fee estimation, replace-by-fee, CPFP etc.
182 2015-11-12 19:08:11 <gavinandresen> If the plan is “smarter wallets that raise fees appropriately” then great.  That needs to be communicated.
183 2015-11-12 19:08:17 <petertodd> gavinandresen: we already have that
184 2015-11-12 19:08:21 <BlueMatt> gavinandresen: wallets already did that
185 2015-11-12 19:08:31 <phantomcircuit> gavinandresen, that is the plan and has been communicated directly to all of the wallet devs for months
186 2015-11-12 19:08:32 <BlueMatt> that was +/- the only impact the spam attack had
187 2015-11-12 19:08:38 <BlueMatt> (well, that and the relay network :(((    )
188 2015-11-12 19:08:52 <phantomcircuit> indeed if you open up the google you will find many of them implemented dynamic fees without the last few months
189 2015-11-12 19:09:03 <sipa> well at least bitcoin core's wallet will need to support that too!
190 2015-11-12 19:09:22 <BlueMatt> we have the fee estimator stuff?
191 2015-11-12 19:09:23 <BlueMatt> its not bad
192 2015-11-12 19:09:28 <petertodd> sipa: AFAIK many of the wallet providers use bitcoin core's fee estimation
193 2015-11-12 19:09:37 <BlueMatt> in fact, many people "implemented dynaic fees" buy just using bitcoin core's
194 2015-11-12 19:10:03 <morcos> please review #6134 on that note!
195 2015-11-12 19:10:15 <sipa> petertodd: hmm, that's good for a baseline, but i would expect that some mechanism to respend with higher fees is available
196 2015-11-12 19:10:19 <BlueMatt> anyway, back to the actual topic....
197 2015-11-12 19:10:30 <BlueMatt> I think removing priority in 0.12 is fine
198 2015-11-12 19:10:37 <morcos> ok, will someone volunteer to email -dev and let them know this is the plan then?
199 2015-11-12 19:10:38 <BlueMatt> if it is announced in the next weeks
200 2015-11-12 19:10:42 <BlueMatt> morcos: willdo
201 2015-11-12 19:10:53 <wumpus> #action please review #6134 (Improve usage of fee estimation code)
202 2015-11-12 19:10:58 <jtimon> sipa: that makes some form of RBF a priority
203 2015-11-12 19:11:07 <petertodd> sipa: mycelium for example has multiple levels of fees that you can easily select
204 2015-11-12 19:11:14 <BlueMatt> next topic: rbf for 0.12?
205 2015-11-12 19:11:22 <BlueMatt> (though i think the answer there may just be "YES")
206 2015-11-12 19:11:24 <morcos> then i think we could skip sdaftuar's 6992 and we could skip dynamic priority 6357
207 2015-11-12 19:11:27 <morcos> (hold on)
208 2015-11-12 19:11:32 <wumpus> RBF: https://github.com/bitcoin/bitcoin/pull/6871
209 2015-11-12 19:11:52 <morcos> but we'll be having another regression in the mining code, by making those who still want to mine by priority, only have access to starting priority
210 2015-11-12 19:12:00 <morcos> is that also an ok regression?
211 2015-11-12 19:12:11 <BlueMatt> morcos: we could rip out all priority stuff in 0.12?
212 2015-11-12 19:12:17 <morcos> we should also default block priority size to 0 and comment about further deprecation in the future
213 2015-11-12 19:12:27 <petertodd> morcos: well, a lot of miners have turned off priority anyway; I'd let them make that decision and give us some feedback
214 2015-11-12 19:12:46 <BlueMatt> morcos: we could backport default block priority size to 0....
215 2015-11-12 19:12:57 <BlueMatt> but i wouldnt think we should
216 2015-11-12 19:13:21 <sipa> ... i just wished we could replace priority with an adjusted fee metric...
217 2015-11-12 19:13:38 <gavinandresen> morcos: yes, I think that is an OK regression.
218 2015-11-12 19:13:44 <morcos> thanks gavinandresen
219 2015-11-12 19:13:52 <btcdrak> sipa: what would that look like?
220 2015-11-12 19:14:04 <CodeShark> it ultimately is a balance between rational behavior and how lazy miners are in changing defaults :)
221 2015-11-12 19:14:23 <BlueMatt> sipa: meh, I'm not so sure
222 2015-11-12 19:14:33 <jtimon> morcos: why this deprecation needs to be in 2 steps?
223 2015-11-12 19:14:40 <morcos> if we've stopped fully supporting priority, it only makes sense to change the default blockpriority size to 0, doesn't need to be backported
224 2015-11-12 19:14:53 <BlueMatt> morcos: ack
225 2015-11-12 19:14:58 <sipa> BlueMatt: i said i wished; i'm not convinced it is possible in a useful way
226 2015-11-12 19:15:01 <morcos> jtimon: primarily bc it hasn't be discussed very much yet
227 2015-11-12 19:15:11 <BlueMatt> sipa: we could have something for relay that isnt the same as mining (years ago there was some discussion of "relay policy is what *you* want to be mined", miners can do the rational thing)
228 2015-11-12 19:15:20 <wumpus> jtimon: to give some advance warning before completely removing it
229 2015-11-12 19:15:22 <BlueMatt> sipa: ok, well then I agree
230 2015-11-12 19:15:40 <jtimon> morcos: I believe this has been a recurring discussion ever since we wanted to limit the mempool size
231 2015-11-12 19:15:44 <morcos> anyway, i think the new 2 step process avoids adding new complication now.  presents a mostly consistent release, and allows us to rip all this stuff right out as soon as we branch off 0.12
232 2015-11-12 19:15:55 <sipa> jtimon: but it has only been a discussion among developers
233 2015-11-12 19:15:57 <wumpus> yes
234 2015-11-12 19:16:20 <petertodd> morcos: well, if we're not *ready* to rip that code away, I 100% agree we should just set the default to zero, but if we're ready to rip that code away, I see no reason to delay
235 2015-11-12 19:16:46 <jtimon> ok, default to zero as a first step and remove in 0.13 ?
236 2015-11-12 19:16:57 <Luke-Jr> we should absolutely not remove priority..
237 2015-11-12 19:17:07 <CodeShark> ?
238 2015-11-12 19:17:17 <btcdrak> Luke-Jr: why?
239 2015-11-12 19:17:31 <Luke-Jr> it's the best metric Core's default policy supports right now..
240 2015-11-12 19:17:40 <BlueMatt> Luke-Jr: no, feerate is
241 2015-11-12 19:17:43 <gmaxwell> I thought sipa has a good way to rationalize it that should be exploired. It would eliminate the multiple objective optimization.
242 2015-11-12 19:17:44 <jg_taxi> Nearly universal  consensus to remove - except for Luke :)
243 2015-11-12 19:17:58 <Luke-Jr> BlueMatt: feerate often isn't.
244 2015-11-12 19:17:59 <phantomcircuit> morcos, we should not be carrying code complex efficient dynamic priority calculation
245 2015-11-12 19:18:05 <morcos> gmaxwell: multiple objective optimization isn't that hard
246 2015-11-12 19:18:09 <BlueMatt> gmaxwell: yes, we should explore adjustments to feerate, but the priority code as it exists should be ripped out
247 2015-11-12 19:18:10 <jtimon> we should only have a cost function (currently txSize) and a reward function (currently fees)
248 2015-11-12 19:18:12 <morcos> phantomcircuit: right, we will skip adding that
249 2015-11-12 19:18:29 <phantomcircuit> i rewrote that sentence one time too few
250 2015-11-12 19:18:36 <gmaxwell> morcos: not fundimentally hard but unnecessary code and computional complexity.
251 2015-11-12 19:18:42 <petertodd> Luke-Jr: I think what we need is "multi-mempool" support, to make it easier to deal with multiple different metrics - e.g. a pool with polcies like Eligius certainly would want to have an easy time setting up a seperate priority-based mechanism
252 2015-11-12 19:18:44 <Luke-Jr> also shouldn't be changing defaults to try to influence miners, outside of emergencies.
253 2015-11-12 19:18:58 <jtimon> after we unify that it's much simpler to change the cost/reward functions
254 2015-11-12 19:19:04 <jg_taxi> Fee deltas can produce priority
255 2015-11-12 19:19:08 <petertodd> Luke-Jr: same reason I think we *should* have a non-feerate mechanism for tx propagation that doesn't interact with the feerate based mechanism
256 2015-11-12 19:19:13 <petertodd> jg_taxi: yup
257 2015-11-12 19:19:19 <gmaxwell> the thing sipa suggests eliminates all impact of priority except in the cost calculation.
258 2015-11-12 19:19:23 <BlueMatt> Luke-Jr: we're not chaning to try to influence miners, we're changing to keep shit from breaking when miners disable priority anyway
259 2015-11-12 19:19:24 <morcos> what i'm proposing is basically shipping 0.12 as is with respect to priority, with a couple of changes: mining code will use starting priority, default prioritysize=0, and wallet is smart enough to not place priority txs if mempool limiting is in effect
260 2015-11-12 19:19:31 <jg_taxi> Thus you can do priority without priority code
261 2015-11-12 19:19:49 <BlueMatt> morcos: which seems reasonable
262 2015-11-12 19:19:59 <morcos> so thats the fewest changes from now to a semi-consistent state.   more ripping out can then be done in 0.13.   if we're not going to rip it out, we should do more now to make it work better, but sounds like we are
263 2015-11-12 19:20:00 <jg_taxi> Ack 0
264 2015-11-12 19:20:14 <BlueMatt> though I really want to rip out the code (its a big churn, though, so we can push back)
265 2015-11-12 19:20:15 <petertodd> morcos: I'd be inclined to make the wallet not use priority at all by default
266 2015-11-12 19:20:32 <Luke-Jr> morcos: the first should be optional, at least
267 2015-11-12 19:20:37 <sipa> jg_taxi, gmaxwell: my idea was to take the btcdaysdestroued of a transaction, divide that by the average utxo age, take a small fraction of that (1%) and add that as extra fee
268 2015-11-12 19:20:57 <Luke-Jr> BlueMatt: I don't know what you mean. Why would things break?
269 2015-11-12 19:20:59 <sipa> jg_taxi, gmaxwell: the problem is that that has no bound on how much fees can be lost by a miner
270 2015-11-12 19:21:05 <Luke-Jr> and why must default policy be changed to prevent it?
271 2015-11-12 19:21:12 <petertodd> morcos: main thing is I just don't want users to get their txs stuck, especially since full RBF and CPFP support isn't in the wallet yte
272 2015-11-12 19:21:28 <morcos> ok i agree with petertodd , lets default QT to no longer send free also.  bitcoind already has that off
273 2015-11-12 19:21:31 <sipa> Luke-Jr: multiple sorting orders is a massive complication to maintain...
274 2015-11-12 19:21:38 <Luke-Jr> morcos: doesn't it already?
275 2015-11-12 19:21:47 <morcos> QT is default on
276 2015-11-12 19:21:55 <jtimon> Luke-Jr: maintaining that code while doing other changes to the mempool behaviour is costly
277 2015-11-12 19:22:02 <jg_taxi> Once opt in RBF is there wallet will have smarter policies in this area
278 2015-11-12 19:22:10 <Luke-Jr> sipa: better to maintain complicated code than to make flexible policy code more complicated to write
279 2015-11-12 19:22:11 <phantomcircuit> petertodd, how do you relay transactions that you're not keeping in the mempool though?
280 2015-11-12 19:22:20 <phantomcircuit> (especially if there's opt in RBF for them)
281 2015-11-12 19:22:23 <gmaxwell> sipa: you can simply cap the impact; thats a candidate for the only tunable for that approach.
282 2015-11-12 19:22:51 <petertodd> phantomcircuit: well, I'm thinking in the future we won't just have one mempool, or one way fo relaying - e.g. it'd be a trivial hack to do tx relaying by bitmessage :)
283 2015-11-12 19:23:00 <gmaxwell> From a code perspective what sipa suggests is largely orthorgonal with removing priority (actually, it wants priority removed); but from a communication perspective it's different.
284 2015-11-12 19:23:21 <sipa> gmaxwell: that does mean it should work first...
285 2015-11-12 19:23:38 <morcos> Luke-Jr: The problem is its impossible to meaningfully speed up CreateNewBlock unless you are A) dynamically calculating priority on the fly as in 6357 or B) changing to a static definition of priority.
286 2015-11-12 19:23:53 <Luke-Jr> if simpler mempool code, makes it harder to write mining policy code, then the simpler mempool policy code should be rejected.
287 2015-11-12 19:23:58 <BlueMatt> gmaxwell: I'm really not sold on doing an adjustment metric....I mean we could, as long as it has a limited impact and I'd be fine with that, but then what was the point?
288 2015-11-12 19:24:04 <morcos> I really think we need the performance improvement in CNB, so we have to pick A or B.  People don't like adding the complication of A, so B it is
289 2015-11-12 19:24:11 <BlueMatt> gmaxwell: mostly I think we should only do it for relay, not mining, but then there is actually no point
290 2015-11-12 19:24:13 <jg_taxi> It sounds like there needs to be a minor hook related to this anyway
291 2015-11-12 19:24:21 <gmaxwell> luke's argument as I understand it is that in recent months we'd generally seen dos attackers as more willing and able to pay just over market rate fees than joe user; even though many wallets have caught up with dynamic fee behavior. Part of this is due to the market rate fees being so low that most of the cost of adjustment is the lack of RBF (which doesn't bother attackers) rather than the fee its
292 2015-11-12 19:24:24 <jtimon> Luke-Jr: you don't have to remove priority in your branch
293 2015-11-12 19:24:27 <gmaxwell> elf.  But all this may be a temporary effect.
294 2015-11-12 19:24:27 <Luke-Jr> morcos: or recalculate priorities each block
295 2015-11-12 19:24:41 <Luke-Jr> jtimon: the changes being proposed make that impossible
296 2015-11-12 19:24:48 <morcos> Luke-Jr: That requries accessing every input for every tx in the mempool
297 2015-11-12 19:24:58 <sipa> Luke-Jr: not impossible, just expensive
298 2015-11-12 19:25:02 <Luke-Jr> morcos: it doesn't need to.
299 2015-11-12 19:25:10 <morcos> that's option A
300 2015-11-12 19:25:20 <gmaxwell> BlueMatt: even a limited impact is likely useful for getting non-dos-attack transactions sorted higher.
301 2015-11-12 19:25:37 <BlueMatt> Luke-Jr: there is a fee-adjustment api for this, it can be tweaked into being your priority calculator
302 2015-11-12 19:25:44 <jtimon> Luke-Jr: as "impossible" as reverting a merged change in master, don't you mean hard to maintain? why should bitcoin core bear that cost instead?
303 2015-11-12 19:25:45 <BlueMatt> gmaxwell: sure, but do we get miners to use it as well?
304 2015-11-12 19:25:45 <petertodd> gmaxwell: the speed at which wallet authors have adopted dynamic fees makes me pretty optimistic that dos attackers won't be doing too much harm - the cost to pay over "market rate" is really, really high
305 2015-11-12 19:25:47 <Luke-Jr> BlueMatt: priority is not fee-adjustment.
306 2015-11-12 19:26:12 <gavinandresen> +1 for using the adjust api if you want something weird. And I vote for simple and fast for createnewblock
307 2015-11-12 19:26:14 <phantomcircuit> this all fundamentally comes down to a simple question; do you believe that user real users will pay higher fees than non-users?
308 2015-11-12 19:26:32 <gmaxwell> phantomcircuit: that overly simplifies.
309 2015-11-12 19:26:37 <BlueMatt> phantomcircuit: meh, we cant do anything if they arent
310 2015-11-12 19:26:45 <petertodd> BlueMatt: agreed there
311 2015-11-12 19:26:51 <Luke-Jr> BlueMatt: they aren't in practice.
312 2015-11-12 19:26:54 <gmaxwell> Because it ignores prediction error costs which are high right now due to a lack of replacement.
313 2015-11-12 19:27:01 <sdaftuar> BlueMatt: i think mempool limiting needs to be updated to take into account fee-deltas
314 2015-11-12 19:27:03 <BlueMatt> Luke-Jr: then we're fucked, lets all go home
315 2015-11-12 19:27:04 <phantomcircuit> gmaxwell, yes... but we can fix that
316 2015-11-12 19:27:13 <phantomcircuit> speaking of which where are we with opt in rbf?
317 2015-11-12 19:27:15 <BlueMatt> sdaftuar: oh? I thought it did that?
318 2015-11-12 19:27:18 <morcos> The topic was what to do for 0.12.  The nice thing about my suggested approach is its minimal changes for now, and allows us to keep arguing indefinitely about prioirty next release cycle, but with a slight nudge towards deprecation.
319 2015-11-12 19:27:26 <BlueMatt> sdaftuar: then, yes, it really does need to be updated if it doesnt
320 2015-11-12 19:27:34 <sdaftuar> (double checking)
321 2015-11-12 19:27:38 <BlueMatt> phantomcircuit: thats the next topic, be patient :)
322 2015-11-12 19:27:39 <petertodd> phantomcircuit: wumpus code reviewed ACKed it
323 2015-11-12 19:28:07 <BlueMatt> morcos: I thought your suggestion included disabling priority for wallet when you see a limited mempool?
324 2015-11-12 19:28:12 <jgarzik> I tested opt-in with a simple replacement.  Need to re-review but overall ACK
325 2015-11-12 19:28:13 <BlueMatt> morcos: I would call that a pretty hard deprecation
326 2015-11-12 19:28:20 <btcdrak> Link for the RBF patch https://github.com/bitcoin/bitcoin/pull/6871
327 2015-11-12 19:28:22 <BlueMatt> morcos: given mempool sizes
328 2015-11-12 19:28:22 <morcos> morcos: thats already in master!
329 2015-11-12 19:28:25 <morcos> BlueMatt: i mena
330 2015-11-12 19:28:28 <Luke-Jr> morcos: so the current behaviour remains possible?
331 2015-11-12 19:28:32 <gmaxwell> morcos: I think what you're suggesting is okay for now. I am only commenting because I do not share BlueMatt/Petertodd/etc. view on the utility of priority like things.
332 2015-11-12 19:28:35 <BlueMatt> jgarzik: please wait for topic change
333 2015-11-12 19:28:50 <CodeShark> I don't think we'll ever finish this topic :p
334 2015-11-12 19:28:55 <jgarzik> BlueMatt, talk to phantomcircuit he started it :)
335 2015-11-12 19:29:00 <wumpus> time for topic change?
336 2015-11-12 19:29:04 <btcdrak> yes!
337 2015-11-12 19:29:07 <CodeShark> please!
338 2015-11-12 19:29:07 <phantomcircuit> ya
339 2015-11-12 19:29:08 <BlueMatt> can we ack the current proposal?
340 2015-11-12 19:29:09 <cfields> yes
341 2015-11-12 19:29:10 <BlueMatt> first
342 2015-11-12 19:29:12 <wumpus> #topic RBF opt-in
343 2015-11-12 19:29:17 <BlueMatt> morcos' proposal acks?
344 2015-11-12 19:29:17 <CodeShark> ACK
345 2015-11-12 19:29:20 <petertodd> ACK
346 2015-11-12 19:29:21 <jgarzik> ACK
347 2015-11-12 19:29:22 <btcdrak> ACK
348 2015-11-12 19:29:26 <wumpus> ACK
349 2015-11-12 19:29:27 <BlueMatt> ok, new topic :)
350 2015-11-12 19:29:27 <sipa> ACK
351 2015-11-12 19:29:29 <sdaftuar> sdaftuar was here
352 2015-11-12 19:29:30 <gmaxwell> ACK
353 2015-11-12 19:29:31 <CodeShark> hehe
354 2015-11-12 19:29:32 <morcos> Luke-Jr: you'd be able to approximate the current behavior.  I f you started with a large mempool, you could still send prioirty txs, and if you were willing to forgo the slight diff in static vs actual priority
355 2015-11-12 19:29:35 <btcdrak> #link https://github.com/bitcoin/bitcoin/pull/6871
356 2015-11-12 19:29:36 <Luke-Jr> NACK if current policy is made impossible
357 2015-11-12 19:29:44 <jtimon> I got lost, what is the current proposal?
358 2015-11-12 19:29:49 <btcdrak> RBF
359 2015-11-12 19:29:55 <CodeShark> opt-in RBF
360 2015-11-12 19:30:05 <phantomcircuit> oh boy
361 2015-11-12 19:30:06 <wumpus> jtimon: set prioritysize to 0 for 0.12, rip out priority for 0.13
362 2015-11-12 19:30:19 <BlueMatt> wumpus: and disable priority in wallet if mempool is limited
363 2015-11-12 19:30:21 <jtimon> ok, ack both
364 2015-11-12 19:30:29 <morcos> jtimon: shipping 0.12 as is with respect to priority, with a couple of changes: mining code will use starting priority, default prioritysize=0, and wallet is smart enough to  not place priority txs if mempool limiting is in effect
365 2015-11-12 19:30:38 <petertodd> Luke-Jr: the above will make current policy still possible, and give time for something better to be implemented I think
366 2015-11-12 19:30:46 <jgarzik> nod
367 2015-11-12 19:30:54 <BlueMatt> ok, so *now* rbf
368 2015-11-12 19:30:56 <Luke-Jr> petertodd: not if mining code must use starting priority.
369 2015-11-12 19:30:58 <jgarzik> ### really RBF
370 2015-11-12 19:31:13 <petertodd> re: RBF, tools! https://github.com/petertodd/replace-by-fee-tools
371 2015-11-12 19:31:27 <btcdrak> that's a good start
372 2015-11-12 19:31:27 <gmaxwell> Luke-Jr: we'll talk more later.
373 2015-11-12 19:31:27 <petertodd> I wrote tx combining - "incremental sendmany" - yesterday
374 2015-11-12 19:31:30 <wumpus> nice petertodd
375 2015-11-12 19:31:38 <BlueMatt> how much is there to discuss aside from "yes, we want this, code has been heavily concept-ack'ed"?
376 2015-11-12 19:31:42 <morcos> Yay for RBF
377 2015-11-12 19:31:45 <jtimon> RBF: ACK
378 2015-11-12 19:31:53 <morcos> we go from cry to rejoice
379 2015-11-12 19:31:54 <jgarzik> opt-in RBF - ACK
380 2015-11-12 19:31:55 <petertodd> BlueMatt: and running in production at f2pool in the FFS variant
381 2015-11-12 19:31:57 <Luke-Jr> biggest problem for optin RBF is that you can't opt-in per-output
382 2015-11-12 19:31:59 <Luke-Jr> IMO
383 2015-11-12 19:32:00 <btcdrak> I guess action point is to review PR if you havemt
384 2015-11-12 19:32:23 <petertodd> Luke-Jr: yeah, that'd be cool, but very hard to implement, and prolematic re privacy :(
385 2015-11-12 19:32:24 <wumpus> #action review and merge #6871 (nSequence-based Full-RBF opt-in)
386 2015-11-12 19:32:27 <BlueMatt> petertodd: I think we all agree FSS is useless :(
387 2015-11-12 19:32:32 <petertodd> Luke-Jr: nSequence is the only "free to use" field we have :(
388 2015-11-12 19:32:36 <jgarzik> BlueMatt, ACK!
389 2015-11-12 19:32:48 <btcdrak> I would prefer we just went full-RBF. I know the landscape has changed a lot since all the tx flooding
390 2015-11-12 19:32:51 <jgarzik> petertodd, until the TX structure changes
391 2015-11-12 19:32:56 <petertodd> BlueMatt: yeah, and if that changes, we can implement FSS later as an add-on
392 2015-11-12 19:33:04 <jgarzik> well we also have TX version bits
393 2015-11-12 19:33:06 <petertodd> jgarzik: agreed!
394 2015-11-12 19:33:30 <Luke-Jr> jgarzik: this doesn't help per-ouptut I think
395 2015-11-12 19:33:31 <gmaxwell> Luke-Jr: any RBF use (further) breaks the safty of unconfirmed decendants... I don't know how much additional value per output flagging would accomplish even if it were reasonably possible (nowhere to encode it, alas).
396 2015-11-12 19:33:33 <petertodd> for now though, nSequence opt-in is the best we have
397 2015-11-12 19:33:38 <sdaftuar> as i mentioned last week i think an email to the list about how opt-in RBF works is important
398 2015-11-12 19:33:43 <jgarzik> it would be nice to mask out TX version bits ahead of time.  Agree it doesn't help with per-{input,output} stuff.
399 2015-11-12 19:33:44 <petertodd> sdaftuar: will do
400 2015-11-12 19:33:55 <jtimon> suggested topic: version bits
401 2015-11-12 19:34:12 <morcos> Suggested Topic: wumpus was supposed to merge chain limits so we could email -dev list about that as well
402 2015-11-12 19:34:17 <Luke-Jr> petertodd: can this optin-RBF be disabled by nodes?
403 2015-11-12 19:34:19 <jgarzik> #action - everybody take opt-in RBF from concept ACK to [ut] ACK
404 2015-11-12 19:34:39 <petertodd> Luke-Jr: no, but if you want to add a command line switch for that by all means go for it
405 2015-11-12 19:34:40 <BlueMatt> morcos: yea, lets do that
406 2015-11-12 19:35:11 <Luke-Jr> petertodd: IMO nodes should be able to toggle between FSS-or-not, and never/optin/always
407 2015-11-12 19:35:15 <morcos> sorry jgarzik:  s/wumpus/any one of the 5 high elders of Bitcoin/
408 2015-11-12 19:35:35 <phantomcircuit> petertodd, well... technically you can send the replacement optin flag outside of the transaction
409 2015-11-12 19:35:37 <Luke-Jr> (are any anti-RBF people going to block an option for nodes to enable always-full-RBF?)
410 2015-11-12 19:35:45 <petertodd> Luke-Jr: well, write that and pull-req! just a few more lines of code
411 2015-11-12 19:35:54 <phantomcircuit> it's not consensus enforced so it doesn't matter
412 2015-11-12 19:36:47 <wumpus> morcos: #6771 seems quite controversial looking at the comments
413 2015-11-12 19:37:02 <phantomcircuit> Luke-Jr, i predict yes, so please as a separate pull request
414 2015-11-12 19:37:27 <morcos> wumpus: yes we discussed that last week.  its a strong majority in favor, but there is a very vocal minority who are opposed.  its not clear how strongly opposed though.
415 2015-11-12 19:37:31 <jgarzik> ### change topic, people
416 2015-11-12 19:37:43 <jgarzik> #topic chain limits
417 2015-11-12 19:37:44 <btcdrak> wumpus: really? a couple of loud voices only it seems.
418 2015-11-12 19:37:44 <wumpus> ok ,next topic was versionbits by jtimon aaik
419 2015-11-12 19:37:46 <Luke-Jr> jgarzik: I'd particularly like an answer from you on that :P
420 2015-11-12 19:37:46 <wumpus> #topic versionbits
421 2015-11-12 19:37:57 <wumpus> jgarzik: please don't do that, I'm chairing
422 2015-11-12 19:38:16 <morcos> unfortunately we don't think there is much of an otpion, so last time we said we'd merge and email and if all hell breaks loose we could consider reverting, but we have to do what we think is the right choice.  and leaving existing limits is dangerous
423 2015-11-12 19:38:17 <jgarzik> then keep it moving, chair :)
424 2015-11-12 19:38:35 <wumpus> jgarzik: it's kind of annoying if we both change topics
425 2015-11-12 19:38:39 <btcdrak> CodeShark: what is the status of versionbits?
426 2015-11-12 19:38:42 <CodeShark> for versionbits, some think the container stuff I did is a bit excessive
427 2015-11-12 19:38:45 <btcdrak> wumpus: agree one chair.
428 2015-11-12 19:38:51 <sipa> morcos: afaik all the opposing voices had use cases up to a few deep
429 2015-11-12 19:38:54 <wumpus> jgarzik: you can chair next week, ok
430 2015-11-12 19:38:56 <jtimon> there's two implementations, CodeShark's https://github.com/bitcoin/bitcoin/pull/6816 and rusty's (let me look for the link later)
431 2015-11-12 19:38:57 <CodeShark> it has been proposed to stick everything into a single static table
432 2015-11-12 19:39:06 <jgarzik> I'm tempted to write a TX version bits BIP, just to reserve bits for later, separate from block version bits
433 2015-11-12 19:39:11 <gmaxwell> morcos: lets come back to after meeting.
434 2015-11-12 19:39:40 <petertodd> I haven't looked in detail at either softfork version bits code myself, but I don't think it needs to be in v0.12.0 at all, so I'm thinking no rush
435 2015-11-12 19:39:40 <phantomcircuit> jgarzik, fyi there is at least a few transactions in the chain that have weird versions
436 2015-11-12 19:39:51 <jgarzik> phantomcircuit, hmmm interesting
437 2015-11-12 19:39:58 <sipa> petertodd: it will need to be backportable anyway
438 2015-11-12 19:40:14 <petertodd> phantomcircuit: not necessarily a bit deal - there's some blocks with weird versions too, and the soft-fork mechanism handles that fine
439 2015-11-12 19:40:31 <gmaxwell> Versionbits bip needs a minor revisions, proposals need a starting time. It can be just a time for which signaling will begin, or also a time for when counting starts.
440 2015-11-12 19:40:33 <btcdrak> petertodd: no sense in delaying this or dealing with refactoring that will come in 0.13
441 2015-11-12 19:40:48 <CodeShark> I had proposed a starting time in a PR to the bip
442 2015-11-12 19:40:53 <CodeShark> but some opposed it
443 2015-11-12 19:40:58 <gmaxwell> Suggested topic: 0.11.2/0.10.4 release.
444 2015-11-12 19:41:02 <jgarzik> in general we want to push versionbits soonish
445 2015-11-12 19:41:05 <gmaxwell> CodeShark: we have more expirence now.
446 2015-11-12 19:41:07 <sipa> CodeShark: there is very good reason now to have it
447 2015-11-12 19:41:23 <phantomcircuit> petertodd, yes im aware, just saying it's something to keep in mind
448 2015-11-12 19:41:23 <sipa> jgarzik: existing softforks need to complete forst anyway
449 2015-11-12 19:41:29 <wumpus> gmaxwell: I don't understand why you want that as topic, they're already in rc?
450 2015-11-12 19:41:31 <btcdrak> CodeShark: I very much pefer the table approach suggested by rusty.
451 2015-11-12 19:41:32 <jgarzik> nod
452 2015-11-12 19:41:45 <gmaxwell> http://bitcoin.sipa.be/ver-2k.png
453 2015-11-12 19:41:55 <cfields> btcdrak: got a link?
454 2015-11-12 19:41:59 <jtimon> to be clear I never opposed to a starting date
455 2015-11-12 19:42:07 <gmaxwell> wumpus: just to find out if there is anything we need to target to cut the release that you or others are thinking of.
456 2015-11-12 19:42:30 <gmaxwell> (I look at that graph twice a day and worry that it's going to uptick hard without a release out. :) )
457 2015-11-12 19:42:37 <btcdrak> cfields: this was rusty's draft idea: https://github.com/bitcoin/bitcoin/compare/master...rustyrussell:bip-9-versionbits
458 2015-11-12 19:43:06 <cfields> wumpus: want the qt/-fpie change backported to .11.2 ?
459 2015-11-12 19:43:06 <jtimon> btcdrak: thanks
460 2015-11-12 19:43:14 <petertodd> gmaxwell: yeah, very inclined to have a CLTV relese out; I'd only delay 0.11.2/0.10.4 for critical fixes
461 2015-11-12 19:43:16 <jgarzik> cfields, later / different chan
462 2015-11-12 19:43:16 <sipa> what is the topic?
463 2015-11-12 19:43:20 <jgarzik> versionbits
464 2015-11-12 19:43:24 <btcdrak> sipa: versionbits
465 2015-11-12 19:43:27 <wumpus> cfields: too late for that IMO, as gmaxwell says we want them final ASAP
466 2015-11-12 19:43:38 <jgarzik> let's move on - seems main decision is codeshark / rusty - not much actionable right now
467 2015-11-12 19:43:44 <petertodd> jgarzik: agreed
468 2015-11-12 19:43:47 <CodeShark> I had added a deploytime parameter as well, but I took it out: https://github.com/bitcoin/bips/pull/219
469 2015-11-12 19:43:48 <cfields> jgarzik: eh? the question was what's .11.2 waiting for
470 2015-11-12 19:43:51 <cfields> wumpus: ok
471 2015-11-12 19:43:58 <jgarzik> cfields, the topic is versionbits
472 2015-11-12 19:44:00 <jgarzik> cfields, not qt
473 2015-11-12 19:44:01 <btcdrak> CodeShark: better add it back then
474 2015-11-12 19:44:10 <CodeShark> will do
475 2015-11-12 19:44:16 <wumpus> #topic chian limits
476 2015-11-12 19:44:18 <gmaxwell> versionbits isn't actionable yet. starting time should be considered.
477 2015-11-12 19:44:18 <jtimon> in fact I personally think both CodeShark's and rusty's are more complicated than they need to be
478 2015-11-12 19:44:33 <jgarzik> chain limits -- last meeting we decided to push & tell list about it
479 2015-11-12 19:44:42 <gmaxwell> CodeShark: feel free to pull me into a conversation with rusty about starting time.
480 2015-11-12 19:44:46 <jgarzik> definitionally impossible to satisfy all
481 2015-11-12 19:44:54 <wumpus> I'm not comfortable with merging it with all the controversy
482 2015-11-12 19:44:58 <jgarzik> I am
483 2015-11-12 19:44:59 <petertodd> re: chian limits, I keep thinking that the # of users actually affected by them is reasonably small, and they tend to be people with engineering teams who should be able to at least do the easy hack of "create a buffer of txs waiting to go out"
484 2015-11-12 19:45:07 <morcos> wumpus: are you comfortable with someone merging it?
485 2015-11-12 19:45:09 <CodeShark> will do, gmaxwell
486 2015-11-12 19:45:10 <btcdrak> gmaxwell: I thought we were all in that discussion
487 2015-11-12 19:45:13 <jtimon> I opposed to having a per-bip threshold instead of per-chain
488 2015-11-12 19:45:14 <BlueMatt> jgarzik: go do it
489 2015-11-12 19:45:17 <jgarzik> OK
490 2015-11-12 19:45:26 <gmaxwell> I am fine with jgarzik merging it. We can revert based on response if needed.
491 2015-11-12 19:45:32 <CodeShark> yeah, actually I think I also added you to the convo, gmaxwell
492 2015-11-12 19:45:35 <petertodd> gmaxwell: +1
493 2015-11-12 19:45:37 <CodeShark> but this was a few weeks ago
494 2015-11-12 19:45:39 <btcdrak> gmaxwell: +1
495 2015-11-12 19:45:44 <sipa> petertodd: they don't even need them to be mined at once; they just nees to get them in the mempool at once so customers can see the transactions
496 2015-11-12 19:45:45 <jgarzik> merge easy, revert easy
497 2015-11-12 19:45:49 <jgarzik> get Internet feedback
498 2015-11-12 19:45:50 <wumpus> blah
499 2015-11-12 19:45:53 <gmaxwell> CodeShark: I might have been stupid then.
500 2015-11-12 19:45:55 <petertodd> sipa: yes I know :(
501 2015-11-12 19:46:05 <gmaxwell> wumpus: I think it will actually be okay but we need more information if not.
502 2015-11-12 19:46:14 <jgarzik> nod
503 2015-11-12 19:46:25 <petertodd> sipa: we should definitely communicate the RBF sendmany alternative to long chains ASAP
504 2015-11-12 19:46:32 <sipa> petertodd: if people were justnusing payment protocol etc, and not using the p2p network as a communication channel, nobody would care
505 2015-11-12 19:46:33 <morcos> ok after it's merged I will email the list
506 2015-11-12 19:46:40 <jgarzik> ok
507 2015-11-12 19:46:44 <petertodd> sipa: agreed
508 2015-11-12 19:46:47 <gmaxwell> wumpus: the cases people raised were all for small chain counts; and large chains cannot be safely supported by the software (of course you can still author large chains, you just need to retransmit until nodes take them-- not unlike other limits... not even clear to me that people knew this)
509 2015-11-12 19:47:17 <sipa> gmaxwell: read my conversation with petertodd above
510 2015-11-12 19:47:32 <gmaxwell> Long chains are still also highly malleability vulnerable.
511 2015-11-12 19:47:33 <petertodd> re: "customer sees tx in wallet" - the user experience of long chains isn't great anyway, as they're not all that reliable due to propagation failures
512 2015-11-12 19:47:39 <jgarzik> yup
513 2015-11-12 19:47:44 <sipa> gmaxwell: retransmit doesn't work for them, it is not mining; it is about getting them instantly relayed
514 2015-11-12 19:47:55 <wumpus> right
515 2015-11-12 19:47:57 <gmaxwell> sipa: fair point though also petertodd's response.
516 2015-11-12 19:48:16 <petertodd> gmaxwell: RBF sendmany won't show up in many users wallets yet :(
517 2015-11-12 19:48:32 <jgarzik> get opt-in RBF into tree, and it will show up in wallets rapidly.
518 2015-11-12 19:48:33 <morcos> I think this is the reason to announce this as far in advance as possible
519 2015-11-12 19:48:38 <petertodd> jgarzik: agreed
520 2015-11-12 19:48:40 <gmaxwell> petertodd: I think showing up in wallets isn't the actual metric, showing up in block explorers is.
521 2015-11-12 19:48:53 <morcos> So that if they need to figure out another way to communicate the information they can
522 2015-11-12 19:48:58 <btcdrak> jgarzik: +!
523 2015-11-12 19:49:06 <morcos> also its a configurable limit!, we're just chanigng the default
524 2015-11-12 19:49:09 <petertodd> gmaxwell: good point - although it'll take awhile for even that to be handled well rather than as scary doublespends
525 2015-11-12 19:49:23 <jgarzik> morcos, agree but weak argument - most go with default
526 2015-11-12 19:49:41 <btcdrak> gmaxwell: we can contact popular explorers to make changes. Shouldnt be hard.
527 2015-11-12 19:49:41 <wumpus> morcos: yes it's not a consensus change :)
528 2015-11-12 19:49:46 <sipa> indeed; defaults has anlot.of power unfortunately
529 2015-11-12 19:49:53 <morcos> the default should be one that allows the node to operate securely and be safe from attack, if more risky parameters are needed for rarer use cases that should be something those users worry about
530 2015-11-12 19:49:56 <gmaxwell> In any case I think collectively we dont think failing to limit here is technically viable. So what choice do we have? people can have their own opinions, but not your own reality. :)
531 2015-11-12 19:50:17 <morcos> gmaxwell: exactly
532 2015-11-12 19:50:18 <jgarzik> ### 10min
533 2015-11-12 19:50:20 <gmaxwell> if there are specific needs about very long chains we need to know so we can figure out how to handle them.
534 2015-11-12 19:50:26 <petertodd> gmaxwell: agreed - first priority is to keep the system working for the super majority who don't need long chains
535 2015-11-12 19:50:37 <jgarzik> gmaxwell, yep -- and merging is the best way to get user feedback on that, IMO
536 2015-11-12 19:50:47 <wumpus> gmaxwell: that's true - the only thing under discussion is what the limits should be, not whetehr there should be any
537 2015-11-12 19:50:52 <phantomcircuit> gmaxwell, nobody commenting in the pull request came up with an actual use case for very long chains, they merely asserted that they needed them
538 2015-11-12 19:50:55 <jgarzik> can only spin wheels so long in the dev silo (info vacuum)
539 2015-11-12 19:51:00 <btcdrak> what is the PR for chainlimits again?
540 2015-11-12 19:51:04 <jgarzik> #6771
541 2015-11-12 19:51:05 <phantomcircuit> which i am happy to ignore
542 2015-11-12 19:51:21 <btcdrak> #link https://github.com/bitcoin/bitcoin/pull/6771
543 2015-11-12 19:51:32 <jgarzik> new topic?
544 2015-11-12 19:51:39 <jtimon> 25 25 wasn't final, right
545 2015-11-12 19:51:57 <morcos> 25 / 101 and 25 / 101  are the final limits
546 2015-11-12 19:52:34 <jtimon> same for both? I expected ancestors to be lower
547 2015-11-12 19:53:04 <morcos> jtimon: most common use case is linear chain...
548 2015-11-12 19:53:23 <sipa> new topic?
549 2015-11-12 19:53:26 <wumpus> any other topics?
550 2015-11-12 19:53:44 <petertodd> <crickets>
551 2015-11-12 19:53:46 <jgarzik> did we cover jonas while I was in the taxi?
552 2015-11-12 19:54:09 <sdaftuar> ?
553 2015-11-12 19:54:10 <jtimon> ?
554 2015-11-12 19:54:20 <CodeShark> not sure I want to know
555 2015-11-12 19:54:20 <Luke-Jr> ?
556 2015-11-12 19:54:23 <petertodd> ‽
557 2015-11-12 19:54:30 <Luke-Jr> ⁈
558 2015-11-12 19:54:42 <CodeShark> sounds kinky, though
559 2015-11-12 19:54:42 <jgarzik> proposal for new GUI maintainer
560 2015-11-12 19:54:52 <petertodd> CodeShark: GUI's are pretty kinky
561 2015-11-12 19:55:10 <BlueMatt> petertodd: they're masochistic, if nothing else
562 2015-11-12 19:55:13 <gmaxwell> jgarzik: I think it's kind of rude to bring that up in this meeting when wumpus probably hasn't talked to jonasschnelli about it! :)
563 2015-11-12 19:55:28 <jgarzik> gmaxwell, he said he did, which is why I mentioned it
564 2015-11-12 19:55:39 <wumpus> it's not time to talk about that yet
565 2015-11-12 19:55:42 <Luke-Jr> jonas also doesn't seem to be here for the meeting
566 2015-11-12 19:55:44 <wumpus> yes, that very rude
567 2015-11-12 19:55:48 <gmaxwell> ah. Okay.
568 2015-11-12 19:56:01 <wumpus> I asked if he was interested, not whether we should announce it yet
569 2015-11-12 19:56:06 <BlueMatt> ok, end meeting?
570 2015-11-12 19:56:24 <btcdrak> if we can remember the command this week :-)
571 2015-11-12 19:56:30 <wumpus> #meetingend
572 2015-11-12 19:56:39 <gmaxwell> #destroymeeting
573 2015-11-12 19:56:42 <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-11-12-19.01.log.html
574 2015-11-12 19:56:42 <lightningbot> Meeting ended Thu Nov 12 19:56:42 2015 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
575 2015-11-12 19:56:42 <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-11-12-19.01.html
576 2015-11-12 19:56:42 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-11-12-19.01.txt
577 2015-11-12 19:56:42 <Luke-Jr> #endmeeting
578 2015-11-12 19:56:42 <wumpus> #endmeeting
579 2015-11-12 19:56:47 <BlueMatt> #magicmeetbotincantation
580 2015-11-12 19:57:01 <petertodd> #DoWhatIMean
581 2015-11-12 19:57:05 <btcdrak> every week lol
582 2015-11-12 19:57:09 <jgarzik> sys_dwim()
583 2015-11-12 19:57:47 <gmaxwell> Luke-Jr: on priority. the exact current behavior requires walking all inputs for all transactioin in the mempool on every CNB to update priorities. With large mempools this is an enormous amount of time, and we cannot continue doing this.
584 2015-11-12 19:58:00 <sharperguy> Has anyone seen this error when building libbitcoin? "/usr/local/include/boost/test/tools/old/impl.hpp:92: undefined reference to `boost::test_tools::tt_detail::report_assertion..."
585 2015-11-12 19:58:11 <morcos> gmaxwell: in core-dev
586 2015-11-12 19:58:13 <jonasschnelli> sorry. was offline.
587 2015-11-12 19:58:20 <btcdrak> sipa: thanks for the code-review today on #6312
588 2015-11-12 19:59:40 <phantomcircuit> sharperguy, #libbitcoin
589 2015-11-12 20:00:09 <wumpus> cfields: we should the qt/-fPIC detection stuff, but after 0.11.2 and 0.10.4 final have been released
590 2015-11-12 20:00:14 <wumpus> +backport
591 2015-11-12 20:00:35 <cfields> ok
592 2015-11-12 20:00:43 <btcdrak> gmaxwell: note MTP was not backported to 0.10.4.
593 2015-11-12 20:01:26 <wumpus> cfields: (which we should do tomorrow anyway)
594 2015-11-12 20:01:35 <cfields> yes
595 2015-11-12 20:02:18 <gmaxwell> btcdrak: I know. I doubt 0.10.4 will see much mining deployment.
596 2015-11-12 20:02:20 <wumpus> or maybe even now. you're here now
597 2015-11-12 20:02:44 <btcdrak> gmaxwell: it was my thought too. Well, my excuse for not doing the backport anyway.
598 2015-11-12 20:02:51 <btcdrak> miners should be on 0.11 imo
599 2015-11-12 20:04:43 <jonasschnelli> gmaxwell, jgarzik: wumpus did ask about a GUI maintainer and I'm ready to do it. I hope i can reduce wumpus workload by taking care of everything gui related.
600 2015-11-12 20:05:13 <jgarzik> jonasschnelli, fyi just emailed an apology -- I thought it was OK to disclose given ACKs & your acceptance
601 2015-11-12 20:05:23 <jgarzik> but my error
602 2015-11-12 20:05:28 <wumpus> jonasschnelli: we just weren't supposed to announce it yet :-)
603 2015-11-12 20:05:54 <jonasschnelli> Okay. I see. Sorry then for my response.
604 2015-11-12 20:06:07 <wumpus> jonasschnelli: not your fault!
605 2015-11-12 20:06:32 <jgarzik> yep my bad
606 2015-11-12 20:06:32 <wumpus> jonasschnelli: it's no problem anyway, welcome I suppose :D
607 2015-11-12 20:08:00 <sipa> jonasschnelli: indeed, welcome :)
608 2015-11-12 20:08:23 <jonasschnelli> Super. Thanks guys. :)
609 2015-11-12 20:08:45 <Taek> do most miners start mining on a block before validating it?
610 2015-11-12 20:08:51 <Taek> (SPV miners aside)
611 2015-11-12 20:09:47 <sipa> Taek: that would be by definition validationless mining (which is what SPV mining should be called) :)
612 2015-11-12 20:10:04 <sipa> what is typically called SPV mining has no validation it, not even SPV
613 2015-11-12 20:10:29 <btcdrak> Congratulations jonasschnelli
614 2015-11-12 20:11:41 <Taek> sipa: at first pass, I think it would be sufficient to validate immediately, but start mining on the new block before validation completes. If the POW is valid, you assume that the cost of making the block is greater than the amount of work that can be wasted by sending around an invalid block if the miners will only be doing invalid mining for a few seconds
615 2015-11-12 20:11:59 <Taek> the miners would also have to propagate the block before validating it again
616 2015-11-12 20:12:22 <Taek> I don't have a good grasp on what practical mining looks like today
617 2015-11-12 20:14:26 <gmaxwell> Taek: If I'm short, sorry. I'm tired of people repeating this. I think you need to actually go simulate it; because what you're suggesting really undermines SPV security, as they make a very strong assumption that miners have validated, and because of the exponential distribution fairly large runs of blocks with short times are quite common.
618 2015-11-12 20:15:06 <Taek> gmaxwell: understood. Would probably help to have a document similar to pos.pdf to catch people up
619 2015-11-12 20:15:23 <gmaxwell> There is more or less no such thing as only a couple seconds in mining due to latencies and efficiency losses on work reset. Figure any work issued people are going to work on for at least 30 seconds.
620 2015-11-12 20:16:23 <phantomcircuit> (although the latency problem can be fixed... but only in hardware)
621 2015-11-12 20:16:52 <Ozymandus> Is today the chat on the state of Bitcoin?
622 2015-11-12 20:17:00 <Ozymandus> Just getting my bearings and timetable correct.
623 2015-11-12 20:17:49 <sipa> Ozymandus: you are 77 minutes late; 7PM iceland time
624 2015-11-12 20:19:21 <Ozymandus> Thanks sipa. I'll sort myself out for next week
625 2015-11-12 20:49:43 <jtimon> Luke-Jr: do you have examples in which a separate block space is necessary for implementing a given mining polcy?
626 2015-11-12 20:49:59 <Luke-Jr> jtimon: the current policy!
627 2015-11-12 20:51:18 <sipa> i do think the current policy is suboptimal though for what it is trying to achieve... if i could pay either fee F, or priority P... why would something with fee F/2 and priority P/2 not be acceptable?
628 2015-11-12 20:51:23 <wizkid057> just scanning some of the above conversation, a proper mining implementation shouldn't care how long createblock takes as long as it does complete at some point
629 2015-11-12 20:51:32 <jtimon> Luke-Jr: it could be equivalently implemented without a separated block space (maybe with performance costs if one is not careful)
630 2015-11-12 20:52:28 <Luke-Jr> jtimon: not easily
631 2015-11-12 20:52:50 <jtimon> Luke-Jr: I mean some case in which you believe a separated space is mundamentally necessary
632 2015-11-12 20:52:58 <Luke-Jr> sipa: perhaps. but that's tangent to the matter
633 2015-11-12 20:53:04 <sipa> Luke-Jr: i don't think so
634 2015-11-12 20:53:06 <jtimon> Luke-Jr: agreed not necessarily easy
635 2015-11-12 20:53:12 <Luke-Jr> jtimon: policy code should be easy
636 2015-11-12 20:53:59 <jtimon> it cannot be easy for all posible cases, infinite possible policies is certainly too hard to maintain
637 2015-11-12 20:54:19 <Lightsword> wizkid057, well the issue right now is that a large amount of mining pools do fully rely on CNB and GBT for generating stratum templates
638 2015-11-12 20:54:47 <wizkid057> Lightsword: then they should fix that ;)
639 2015-11-12 20:54:51 <Luke-Jr> jtimon: infinity being too hard, does not justify making non-infinity real-world policies harder
640 2015-11-12 20:55:07 <jtimon> but you can have a common interface and that interface doesn't need to expose separated spaces
641 2015-11-12 20:55:28 <Luke-Jr> jtimon: if it doesn't, you make typical policies significantly harder
642 2015-11-12 20:56:05 <jtimon> Luke-Jr: ok, I'm asking about what part of those "typical policies" will be harder to maintain if priority is removed as it is
643 2015-11-12 20:56:22 <sipa> i think it's only called a typical policy for historical reasons; it may well be possible to write a superior ones more easily
644 2015-11-12 20:56:28 <wizkid057> Lightsword: I think a tweak to bitcoind's blocknotify that also provided the height and bits fields would be more than sufficient to get miners on the right track quickly (basically what I have Eligius doing now)
645 2015-11-12 20:56:43 <Lightsword> wizkid057, I think it’s a fairly complex change for a lot of implementations, in any case the difference it makes when running bitcoind with minrelaytxfee=0.0001 and limitfreerelay=0 seems to be negligable
646 2015-11-12 20:56:51 <jtimon> Luke-Jr: because I have only read about the default policy and I have only imagined what I would do as a miner
647 2015-11-12 20:57:36 <Luke-Jr> in any case, keeping the current policy is fairly cheap
648 2015-11-12 20:57:38 <wizkid057> Lightsword: GBT is always going to be slower than just making a blank template, though
649 2015-11-12 20:57:41 <jtimon> Luke-Jr: tangent ACK on s/standard policy/default policy/ clearer term
650 2015-11-12 20:58:38 <Lightsword> wizkid057, the ckpool based pools which fully rely on GBT seem to be some of the fastest pools to send out stratum updates on block changes however so I think it’s probably something that would be best handled in bitcoind itself
651 2015-11-12 20:58:39 <jtimon> Luke-Jr: of course, changing things while keeping the current policy is the problem
652 2015-11-12 20:59:03 <Luke-Jr> jtimon: but it's not a problem
653 2015-11-12 20:59:10 <jtimon> Luke-Jr: that should be the problem of those who want to maintain the current policy, not Bitcoin Core's for eternity
654 2015-11-12 20:59:39 <Luke-Jr> jtimon: no, it shouldn't.
655 2015-11-12 20:59:40 <wizkid057> Lightsword: maybe a GBT option on the request to not process/return transactions for the first request after a blocknotify would make some sense.  would be a trivial patch for the pool software too to make that request initially
656 2015-11-12 20:59:57 <Luke-Jr> jtimon: Bitcoin Core should not be making policies harder to maintain.
657 2015-11-12 21:00:17 <Luke-Jr> anyhow, as I understand it, 6898+6357 preserves the current policy just fine
658 2015-11-12 21:00:32 <wizkid057> Lightsword: also keep in mind that the ckpool based pools all have minimal load compared to say, Eligius
659 2015-11-12 21:00:33 <jtimon> Luke-Jr: Bitcoin Core doesn't make any policy harder to maintain, all it can do is making some policies easier to maintain
660 2015-11-12 21:00:53 <Lightsword> wizkid057, either that or have a aggressively filtered secondary mempool to generate initial GBT from
661 2015-11-12 21:01:39 <wizkid057> Lightsword: seems overly complicated.  probably less than a dozen lines of code to add a flag to GBT to skip transactions
662 2015-11-12 21:02:07 <Luke-Jr> Lightsword: I propose adding an option to GBT requests "fast", which causes bitcoind to skip the mempool in CNB.
663 2015-11-12 21:02:20 <Luke-Jr> Lightsword: then you can call that for your first template of a new block
664 2015-11-12 21:02:26 <wizkid057> Luke-Jr: I just said that :P
665 2015-11-12 21:02:29 <Luke-Jr> eg, the longpoll request
666 2015-11-12 21:02:38 <Lightsword> wizkid057, I don’t really see any GBT latency issues though when the mempool is under 1MB
667 2015-11-12 21:03:03 <jtimon> bitcoin core will stop making policies that are currently implemented using a separated block space instead of unified cost/reward metrics consciously easier to maintain (but they can still be maintained, it may remain easy forever)
668 2015-11-12 21:03:19 <wizkid057> Lightsword: me either, but that's rare these days with sane limits
669 2015-11-12 21:04:14 <wizkid057> Lightsword: Eligius's mempool is 62MB right now, lol
670 2015-11-12 21:04:48 <Lightsword> wizkid057, that’s why I think the secondary pool just for CNB may be best if it gets refilled from a larger one, the main issue is not running out of RAM it is CNB having to operate on too large a mempool
671 2015-11-12 21:05:16 <jtimon> I should not talk about mathematical proofs I'm not going to provide, but I strongly believe that the domains of all possible policies implementable with and without separated space are equivalent
672 2015-11-12 21:05:32 <wizkid057> a bitcoind I have with completely default settings has a mempoolsize of 1018700445 bytes (1GB!)
673 2015-11-12 21:05:49 <wizkid057> "size" : 75583,
674 2015-11-12 21:05:53 <wizkid057> holy crap that's a lot of spam
675 2015-11-12 21:06:30 <wizkid057> hmm... I should try a GBT on it
676 2015-11-12 21:07:09 <Lightsword> wizkid057, one other option is just having multiple bitcoind instances and setting one with very agressive mempool filtering for fast block changes, while having a larger one for regular stratum updates
677 2015-11-12 21:07:11 <jtimon> Luke-Jr: if you want help rebasing any concrete mining policy on top of a branch without priority, I'm interested
678 2015-11-12 21:07:19 <wizkid057> hmm... going to rule that a non-issue: real    0m19.073s
679 2015-11-12 21:07:37 <Lightsword> which ckpool currently doesn’t support….but may have that added
680 2015-11-12 21:07:48 <wizkid057> 19 seconds to GBT on a crappy dual core machine with 8GB of ram and a 1GB mempool
681 2015-11-12 21:08:16 <wizkid057> Lightsword: really, that's just seriously overcomplicating things
682 2015-11-12 21:08:36 <gmaxwell> 0.12 GBT will many times faster.
683 2015-11-12 21:08:54 <Lightsword> I was seeing 10 seconds on a ~7MB mempool on a high end server
684 2015-11-12 21:09:08 <wizkid057> if my crap box with bitcoind 0.11 and a 1GB mempool can return a GBT in 19 seconds... I see this as a non-issue
685 2015-11-12 21:09:09 <gmaxwell> though part of the reason for this is ... more or less elimiating priority or at least incremental priority update.
686 2015-11-12 21:09:35 <gmaxwell> Lightsword: that sounds suspect even on 0.11.  By "high end server" do you mean some questionable VPS? :)
687 2015-11-12 21:09:44 <wizkid057> Lightsword: I think your definition of high end is questionable
688 2015-11-12 21:10:06 <Lightsword> gmaxwell, AWS with 32GB ram quad core, with little other source of resource usage
689 2015-11-12 21:10:21 <gmaxwell> AWS is often completely IO starved.
690 2015-11-12 21:10:30 <wizkid057> Lightsword: the machine I'm poking at now is an aws t1.small machine
691 2015-11-12 21:10:33 <wangchun> wizkid057: getblocktemplate could get very slow with 1GB spams in mempool, how do you handle it?
692 2015-11-12 21:10:51 <morcos> sipa: jtimon: sorry if i'm behind, but i agree with Luke-Jr, the current policy accomplishes a goal that is not equaly possible to accomplish with a combined metric.  It just may not be currently worth the complication given that its not incentive compatible
693 2015-11-12 21:10:52 <Lightsword> gmaxwell, disk IO?
694 2015-11-12 21:11:09 <wizkid057> wangchun: I just dont care how long GBT takes.  on blocknotify, I start mining immediately with no txns and as soon as GBT returns I update miners
695 2015-11-12 21:11:23 <gmaxwell> I wish I could ban bitcoin core usage on AW; for all the spurrious complaints about performance tracable low disk throughput /  high latency. :(  (not serious but)
696 2015-11-12 21:12:03 <wangchun> wizkid057: It is what they called "SPV mining". They will attack you for doing this.
697 2015-11-12 21:12:22 <wizkid057> wangchun: no, it's not.  I let bitcoind verify the block.
698 2015-11-12 21:12:24 <Luke-Jr> morcos: the complication in this case isn't computationally expensive, so IMO it is worth it
699 2015-11-12 21:12:33 <Lightsword> gmaxwell, with disabling free relay it seems fine though, if there is enough RAM CNB doesn’t even need to touch the disk itself right?
700 2015-11-12 21:12:43 <wangchun> wizkid057: and it generates 1-tx block, doesn't it? Everyone hate 1-tx block.
701 2015-11-12 21:12:56 <Luke-Jr> wangchun: you absolutely should mine empty blocks on blocknotify. that is safe and not SPV mining
702 2015-11-12 21:13:05 <Luke-Jr> it is only good for Bitcoin
703 2015-11-12 21:13:10 <wizkid057> wangchun: sure, if the pool finds a block before GBT returns it's 1-tx.  doesnt hurt anyone.  much ado about nothing.
704 2015-11-12 21:13:39 <wizkid057> adds security, ups confirmation count of in-chain txns, etc
705 2015-11-12 21:13:52 <wangchun> Luke-Jr: But people do not like it. They will get to hate you. In the last four months, we've lost 2.5% due to suspected block withholdings.
706 2015-11-12 21:13:55 <gmaxwell> Lightsword: you'd need a 6gb dbcache to really guarentee that, and then only after the cache is well primed.
707 2015-11-12 21:13:58 <jtimon> morcos: I disagree, a combined metric could reproduce the current policy without a separated space (the easiest way to do so may be a performance disaster), but the point is we don't even want to
708 2015-11-12 21:14:20 <morcos> jtimon: i really don't think so
709 2015-11-12 21:14:27 <Luke-Jr> wangchun: they can hate me all they like. I make my decisions based on reason, not popularity.
710 2015-11-12 21:14:47 <wizkid057> wangchun: I have a conspiracy theory on the whole block withholding thing, but I'll save that for another time
711 2015-11-12 21:14:52 <Luke-Jr> jtimon: debating this is irrelevant and a waste of time better spent on code.
712 2015-11-12 21:14:55 <gmaxwell> wangchun: ignorance can be corrected; though I doubt the withholding attacks are because of 1tx blocks.
713 2015-11-12 21:14:59 <wangchun> Luke-Jr: You are right. I don't care whether they hate me. But I care about the attacks.
714 2015-11-12 21:15:37 <jtimon> Luke-Jr: agreed, please just show me the branch that you think would suffer more if we entirely kill priority
715 2015-11-12 21:15:43 <Luke-Jr> wangchun: a hardfork could conceivably make withholding attacks impossible. maybe we should do that if we have a hardfork.
716 2015-11-12 21:15:46 <Lightsword> gmaxwell, that shouldn’t be an issue, I run 32GB RAM, is there a way to force bitcoind to prime the cache on startup?
717 2015-11-12 21:17:07 <jtimon> Luke-Jr: If I'm not able to maintain the functionality of the policy, then at least will understand your point of view better
718 2015-11-12 21:17:49 <gmaxwell> Lightsword: are you running with -dbcache=8192 or likewise?
719 2015-11-12 21:18:02 <Lightsword> gmaxwell, no, I’m default there
720 2015-11-12 21:18:04 <wizkid057> Lightsword: on dedicated hardware (12 core machine with 32 GB ram, SSD RAID0) Eligius's GBT takes < 10 seconds consistently
721 2015-11-12 21:18:11 <gmaxwell> Lightsword: oh dear.
722 2015-11-12 21:18:25 <gmaxwell> Lightsword: well then your large amount of memory is completely uninteresting from a performance perspective.
723 2015-11-12 21:19:08 <wizkid057> gmaxwell: I thought dbcache had a max of 4096?
724 2015-11-12 21:19:11 <Lightsword> gmaxwell, does it default a lot lower?
725 2015-11-12 21:19:28 <wizkid057> Lightsword: 100MB I think
726 2015-11-12 21:19:50 <gmaxwell> wizkid057: no, 16384 on 64bit.
727 2015-11-12 21:20:21 <wizkid057> hmm
728 2015-11-12 21:20:48 <wangchun> gmaxwell: It's either because of 1tx blocks, or the XT thing, as it all begins from late June/early July.
729 2015-11-12 21:20:52 <Lightsword> linux has its own disk cache though as well right?
730 2015-11-12 21:20:56 <gmaxwell> really 4096 is more than enough to get almost all of the hitrate.
731 2015-11-12 21:21:08 <wizkid057> gmaxwell: that change between 0.10 and 0.11?
732 2015-11-12 21:21:11 <Lightsword> I’m assuming that should be making a difference since frequently accessed files get cached
733 2015-11-12 21:21:31 <jgarzik> BlueMatt, Thanks for emailing bitcoin-dev RE priority!
734 2015-11-12 21:21:33 <gmaxwell> Lightsword: the difference there is very small.
735 2015-11-12 21:21:52 <BlueMatt> jgarzik: hey, sometimes I actually follow through when I say I'm gonna do something :p
736 2015-11-12 21:21:58 <Lightsword> gmaxwell, so I should run with dbcache=8192 in my bitcoin.conf then? or should I try higher?
737 2015-11-12 21:22:34 <jgarzik> BlueMatt, I am pro user communication, it gives me warm fuzzies ;p
738 2015-11-12 21:22:44 <gmaxwell> Lightsword: 8192 is fine. It won't use more than about 6GB right now anyways. Thats enough to get the whole utxo set in ram.
739 2015-11-12 21:23:01 <BlueMatt> jgarzik: yea, we need a better strategy there, actually....like, most "users" dont read bitcoin-dev, even that is an echo chamber :(
740 2015-11-12 21:23:11 <BlueMatt> jgarzik: we need a bitcoin-users-announce list or something
741 2015-11-12 21:23:24 <BlueMatt> (dont take that as a serious suggestion, I dont want more lists)
742 2015-11-12 21:23:42 <gmaxwell> BlueMatt: someone who cares to can, however.  The duty isn't to go out and bang on everyone's door, but to at least make it readily available.
743 2015-11-12 21:23:42 <wizkid057> I read -dev when I have time... lots of activity though, so, hard to keep up sometimes
744 2015-11-12 21:23:47 <jgarzik> BlueMatt, agree w/ sentiment - though I want to be a cheerleader for progress, steps in the right direction
745 2015-11-12 21:23:58 <jgarzik> it has a wider audience than IRC
746 2015-11-12 21:24:04 <gmaxwell> "The plans were on display"
747 2015-11-12 21:24:13 <BlueMatt> wizkid057: you have to be good at reading the first mail and then ignoring that entire topic
748 2015-11-12 21:24:19 <jgarzik> heh
749 2015-11-12 21:24:35 <wizkid057> BlueMatt: lol
750 2015-11-12 21:25:00 <morcos> wumpus: btw i emailed -dev on 10/5 with the proposed lower limits and received basically no response.  one weak nack that said they hadn't yet seen a use case for more than 25.  hope that makes you feel better about the amount of controversy
751 2015-11-12 21:25:21 <wizkid057> “Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”
752 2015-11-12 21:25:51 <gmaxwell> wizkid057: :)
753 2015-11-12 21:25:55 <wumpus> morcos: yes it's a bit strange that some people say to care deeply about it but when you probe further it's not clear what it is about
754 2015-11-12 21:26:22 <phantomcircuit> gmaxwell, gah 19 loc, you monsters!
755 2015-11-12 21:27:55 <Luke-Jr> wizkid057: -dev ML is getting easier to keep up with since it's moderated now
756 2015-11-12 21:32:18 <wumpus> morcos: after reading the comments another time it does seem that most people initially against it their concerns were put mostly at rest
757 2015-11-12 21:32:39 <wumpus> morcos: e.g. 25 is stilll enough, they just don't want it to become even lower
758 2015-11-12 21:34:09 <wizkid057> Luke-Jr: oh... when did that happen?
759 2015-11-12 21:34:24 <Luke-Jr> wizkid057: dunno, maybe a month ago or so
760 2015-11-12 21:52:50 <sipa> morcos: yes, i agree that may be the case; i was talking hypothetically - the current policy is not optimal (for example, it could limit the amount of fees lost rather than set a fixed sze area)
761 2015-11-12 21:54:48 <morcos> sipa: yes i mostly think its not worth trying to do anything different that's also not incentive compatible.
762 2015-11-12 21:57:58 <morcos> oh yeah, btw, not to beat a dead horse, but did you see sturles comment on 6992.  sdaftuar saw the same thing, it does make your mempool more accurately reflect what will be in blocks.  however that to me is a minor reason to support it if we think that effect will go away in time due to less priority space by miners.
763 2015-11-12 21:58:58 <sipa> well if we keep priority space... it likely will all just keep working fine, maybe for years
764 2015-11-12 21:59:09 <sipa> ... for a small number of users with old coins
765 2015-11-12 22:00:06 <sturles> Except for a very few, miners seem to keep priority space.
766 2015-11-12 22:00:31 <sturles> A common misconception here, it seems, is that priority transactions don't pay fees.  They do.
767 2015-11-12 22:00:47 <sipa> they're not required to
768 2015-11-12 22:01:10 <sturles> The may pay less fees than other transactions, but the total fees per KB from the priority space and the rest is not very different.
769 2015-11-12 22:01:23 <sturles> sipa: No, they are not required to, but most do.
770 2015-11-12 22:01:25 <sipa> i think priority transactions only really work because nearly nobody uses them
771 2015-11-12 22:01:55 <sipa> sturles: if the feerate is not very differentz removing the priority rule will not make a difference
772 2015-11-12 22:01:59 <sturles> Bitcoin would have been completely devastated during some of the previous spam attacks if we hadn't had the priority space.
773 2015-11-12 22:02:09 <sipa> i doubt that
774 2015-11-12 22:02:27 <sipa> it's a small percentage of the block space
775 2015-11-12 22:02:37 <sturles> Non-spam trickeled through the storm.  Very few non-spam transactions were significantly delayed, even with much lower fees than the spam.
776 2015-11-12 22:03:06 <sturles> You will be amazed to know how large part of the current blocks are wasted on spam.
777 2015-11-12 22:03:20 <sipa> i am sure about that!
778 2015-11-12 22:03:35 <wizkid057> sturles: I think a good chunk of the help during the spam attacks were a small number of pools doing some filtering...
779 2015-11-12 22:03:39 <sturles> Most legitimate transactions can fit in a very small part of the blocks.  The current priority space is large enough.
780 2015-11-12 22:03:54 <sturles> wizkid057: True.
781 2015-11-12 22:04:04 <sipa> sturles: so you're saying mining fee income should come from spam, that pays for legitimate transactions?
782 2015-11-12 22:04:14 <sipa> what if we get mkre legitimate transactions?
783 2015-11-12 22:04:28 <wizkid057> I got dozens of emails from people with "stuck" transactions thanking me for including their transactions in a block
784 2015-11-12 22:04:29 <sturles> No, I never said that.
785 2015-11-12 22:04:48 <sipa> then the priority space won't be big enough in the long term
786 2015-11-12 22:04:56 <sipa> or the medium term
787 2015-11-12 22:05:17 <sturles> sipa: I say the priority space pays about the same in fees as the rest, even if priority transactions aren't required to pay fees.
788 2015-11-12 22:05:45 <sturles> It may be too small, yes.  We should increase the default somewhat.
789 2015-11-12 22:05:46 <sipa> sturles: if that is the case, removing it will make no difference
790 2015-11-12 22:06:14 <sturles> Yes, it does.  About the same, not exactly the same.
791 2015-11-12 22:06:51 <sturles> See if you can find a difference in income between e.g. BitMinter's blocks (500kB priority space) and those with a lot smaller or no priority space.
792 2015-11-12 22:06:55 <wizkid057> I think some mechanism that both auto adjusts fees based on current conditions, as well as a sane replace-by-fee type setup that allows people to bump their txn fees (possibly automatically up to a limit?) would be the way to go long term
793 2015-11-12 22:07:06 <sipa> well i am still in favor of just using a combined metric that slightly increases the 'virtual fee' by a priority metric
794 2015-11-12 22:07:13 <wizkid057> that way the spammers end up going broke and not causing much havoc, and legit folks have a way in
795 2015-11-12 22:07:24 <sipa> people just fear it will either nkt work, or be gamable
796 2015-11-12 22:08:03 <sturles> I think a combined metric may end up at least as complex as the current situation.  People are going to adjust all kinds of knobs.
797 2015-11-12 22:08:23 <sipa> sturles: i promise you it will be 100s of lines of code less
798 2015-11-12 22:09:02 <sipa> no separate index, no separate fee estimator, no separate mempool space, no logic to selectively sort in CNB, ...
799 2015-11-12 22:09:09 <wizkid057> definitely long term (and maybe even short term with the second subsidy halving coming next year) there is going to have to be some serious changes to how txn fees are handled, for sure
800 2015-11-12 22:09:27 <morcos> sipa: there will be a conversion factor estimator
801 2015-11-12 22:09:35 <sipa> morcos: sure
802 2015-11-12 22:09:41 <sipa> that's 1 line
803 2015-11-12 22:09:49 <sipa> ah
804 2015-11-12 22:10:04 <sipa> hmm, if you think you need to go that far
805 2015-11-12 22:10:29 <morcos> i just think a fixed conversion factor would be just as annoying as the fixed fees in the past were
806 2015-11-12 22:11:21 <sipa> perhaps
807 2015-11-12 22:11:22 <morcos> but you are right, way simpler.  maybe its ok for it to be a manual knob that miners just adjust in time of spam attacks
808 2015-11-12 22:11:28 <sturles> sipa: No matter what changes are made – please run a simulation high fee spam attack to see that normal transactions still get a chance to get through.
809 2015-11-12 22:11:46 <morcos> sturles: there hasn't been a high fee spam attack yet
810 2015-11-12 22:12:02 <morcos> its hard for their to be one, bc its by definition expensive
811 2015-11-12 22:12:51 <wizkid057> spam *should* be prohibitively expensive.  IMO, it is not currently
812 2015-11-12 22:13:06 <dgenr8> morcos: +1, shame if we don't exploit this property to the fullest
813 2015-11-12 22:13:08 <sturles> Yes, there was one using higher than the default fee.  The default when no estimate is available, and for some SPV wallets.
814 2015-11-12 22:14:50 <wizkid057> last I checked I could fill an entire block for like $100 or so
815 2015-11-12 22:14:53 <wizkid057> if I wanted
816 2015-11-12 22:14:55 <dgenr8> sipa: does a priority tweak really help, if a wallet tx can still be dropped? seems like it's fish or cut bait
817 2015-11-12 22:15:08 <wizkid057> that's definitely not prohibitively expensive for someone wanting to cause issues
818 2015-11-12 22:15:28 <kanzure> re: fee estimation, see http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011685.html https://medium.com/@bramcohen/how-wallets-can-handle-transaction-fees-ff5d020d14fb
819 2015-11-12 22:16:25 <Luke-Jr> sipa: the legitimate tx volume is like 300k/block on average. smaller, if we rule out microtransactions. so 27k default priority size is 9% of that
820 2015-11-12 22:17:06 <sipa> morcos: part of the problem in using btcdays as metric is that there is a huge stash of it available in case it would actually become valuable
821 2015-11-12 22:17:29 <Luke-Jr> sipa: it loses its value when transferred.. :P
822 2015-11-12 22:17:52 <Luke-Jr> besides, nobody is adding value to it, just maintaining its current value
823 2015-11-12 22:18:00 <Luke-Jr> which IMO has not been a problem
824 2015-11-12 22:19:10 <wizkid057> I could see some system where btcdays lowered fees enough to be worthwhile being exploited by larger entities with a sufficient buffer to keep their sent coins older
825 2015-11-12 22:19:21 <Luke-Jr> considering there is negative cost to keeping the priority logic in place, the answer is obvious
826 2015-11-12 22:19:22 <sipa> Luke-Jr: imagine we make all mining selection based on just priority
827 2015-11-12 22:19:36 <sipa> Luke-Jr: spam would likely be gone
828 2015-11-12 22:19:52 <sipa> but only people with old coins would be sending transactions
829 2015-11-12 22:20:06 <Luke-Jr> sipa: I'm not recommending that!
830 2015-11-12 22:20:27 <sipa> i know you are not
831 2015-11-12 22:21:05 <sipa> but imagine a place where spammers somehow decide burning huge amounts in fees is ok, and "legitimate" transactions (whatever those are have a hard time competing)
832 2015-11-12 22:21:21 <sipa> now the priority space becomes the new block space to compete for
833 2015-11-12 22:21:31 <sipa> and those who have old coins are privileged
834 2015-11-12 22:21:57 <dgenr8> with priority only, if you don't have old coins, the prescription is "wait".  with fee only, the prescription is "wait until the spammer has spent his wad"
835 2015-11-12 22:22:11 <Luke-Jr> sipa: better than nothing working at all
836 2015-11-12 22:22:44 <dgenr8> OR pay up
837 2015-11-12 22:22:54 <sipa> pay up works :)
838 2015-11-12 22:23:06 <sipa> and i think that in the long term it is the only thing that works
839 2015-11-12 22:23:58 <wizkid057> I think it'd be awesome if after a while (an hour or so) if a sent tx hasn't been mined the client would pester the user, "Hey pal, I bet this transaction would get mined if you re-sent it with a higher fee...."
840 2015-11-12 22:24:05 <sipa> yes
841 2015-11-12 22:24:42 <Luke-Jr> we don't have a good solution to the spam problem. that doesn't mean we shouldn't do the best we can.
842 2015-11-12 22:24:56 <wizkid057> determining the appropriate fee based on current conditions is above my pay grade, but, would be cool if there was a sane way to do so :)
843 2015-11-12 22:25:08 <Luke-Jr> wizkid057: Core already tries
844 2015-11-12 22:26:23 <wizkid057> I mean, is there a setting to include a fee that basically guarantees inclusion in a block soon?  If so, I bet people would use it
845 2015-11-12 22:26:47 <Luke-Jr> wizkid057: you can set it to target the very next block
846 2015-11-12 22:27:17 <wizkid057> fees are pretty darn cheap.  If it costs $0.15 to guarantee quick inclusion vs $0.05 for an indefinite wait... I'd go with the former
847 2015-11-12 22:27:29 <sipa> Luke-Jr: i very much disagree that setting apart two separate spaces for two separate policies is the best we can do
848 2015-11-12 22:27:46 <sipa> Luke-Jr: even when disregarding incentive compatibility with mining
849 2015-11-12 22:27:50 <Luke-Jr> sipa: it's certainly better than the feerate-only policy.
850 2015-11-12 22:27:56 <wizkid057> sipa: I think it's a better than nothing scenario
851 2015-11-12 22:28:17 <wizkid057> gotta run
852 2015-11-12 22:28:25 <sipa> Luke-Jr: perhaps, but that doesn't mean you should keep defending the current solution at all costs
853 2015-11-12 22:28:34 <Luke-Jr> wizkid057: right now, my non-247 Core node estimates 0.00088495 BTC/kB for next-block mining (vs 0.00001014 BTC for 25 blocks)
854 2015-11-12 22:29:06 <Luke-Jr> sipa: as mentioned, the current solution has negative costs. removing it in Core costs more.
855 2015-11-12 22:29:58 <sipa> Luke-Jr: i also very much disagree with that; it is complicating improvements to mempool, mining, estimation, ...
856 2015-11-12 22:30:46 <Luke-Jr> estimation must take it into consideration (or not) regardless of what Core does, since miners may decide to use it despite removal
857 2015-11-12 22:31:22 <Luke-Jr> mining is code I maintain anyway, and I also maintain LJR, so I have to maintain it either way, and it's more work to maintain it separate
858 2015-11-12 22:31:28 <morcos> Luke-Jr: its not possible to estimate using it if you don't have priority txs in your mempool
859 2015-11-12 22:31:39 <morcos> so thats already broken with limited mempool
860 2015-11-12 22:31:54 <morcos> interesting that you have such a low estimate for 25 block confirmation
861 2015-11-12 22:32:16 <morcos> fees.chaincode.com is returning 4373 sat
862 2015-11-12 22:32:46 <Luke-Jr> morcos: my node may not have been running for days
863 2015-11-12 22:32:57 <Luke-Jr> 9 days it looks like
864 2015-11-12 22:33:34 <morcos> still, this attack has been going on a long time...   one possibility is that txs which meet your mempool policy actually do get mined at such a low fee rate...
865 2015-11-12 22:33:50 <Luke-Jr> possible, yes
866 2015-11-12 22:34:18 <sipa> estimation unfortunately relies on knowing other's policies...
867 2015-11-12 22:34:27 <Luke-Jr> hmm, a real-world benefit to setting a sane relay policy: you might get better fee estimates :D
868 2015-11-12 22:37:01 <Luke-Jr> although it'd probably be a good idea to try to figure out a way to account for that in estimation logic