1 2015-07-12 01:53:03 <midnightmagic> dpkg --compare-versions 0.11.0 gt 0.11.0rc2 || { echo nope; }
  2 2015-07-12 01:53:05 <midnightmagic> real helpful debian
  3 2015-07-12 02:22:00 <jgarzik> wumpus, sipa: rofl.  My connection problem was...  a bug in the conversion from select(2) to poll(2) on my local branch.
  4 2015-07-12 02:24:55 <sipa> oh!
  5 2015-07-12 02:58:19 <michagogo> midnightmagic: guessing that falls through to the echo?
  6 2015-07-12 02:59:01 <michagogo> Makes sense. Debian packages have a specific versioning scheme with special characters and meanings.
  7 2015-07-12 02:59:19 <michagogo> You'd need a ~ somewhere in there or something.
  8 2015-07-12 03:07:21 <SpeakFreely> Does anyone here know about the details of ledger fairly well?
  9 2015-07-12 06:55:19 <phantomcircuit> ERROR: CheckTransaction(): vin empty
 10 2015-07-12 06:55:28 <phantomcircuit> from a peer claiming to be Satoshi:0.8.5
 11 2015-07-12 07:51:03 <tobeyrowe> Hi, does anyone on here kow how to make an altcoin?
 12 2015-07-12 07:52:06 <tobeyrowe> hi
 13 2015-07-12 07:52:16 <Adlai> yes, but that's offtopic for here, or #bitcoin. try altcoin-specific channels.
 14 2015-07-12 07:52:56 <drazisil> tobeyrowe: maybe give ##altcoin-dev a try
 15 2015-07-12 07:54:37 <tobeyrowe> okay im trying it out now thank you
 16 2015-07-12 08:14:15 <gmaxwell> wangchun: why are you amplifying the dos attacks?  You are creating thousands and thousands of spendable txouts?
 17 2015-07-12 08:15:01 <gmaxwell> wangchun: https://blockchain.info/tx/827a8782dd7a0a660dffb4b4b0aa325db32006d4ae39518ffc2a7d40e8b87de8
 18 2015-07-12 08:15:02 <tobeyrowe> there is no one on the ##altcoin-dev that is repsonding
 19 2015-07-12 08:15:32 <tobeyrowe> and i really need to get an altcoin made
 20 2015-07-12 08:17:09 <gmaxwell> wangchun: Why are you using a transaction that uses a unique slow to verify signature for every transaction, and instead of reducing the utxo size you are simply taking the coins and leaving a spendable txout?
 21 2015-07-12 08:19:18 <tobeyrowe> can someone please help me build a digital currency?
 22 2015-07-12 08:19:38 <drazisil> guess the timeout didn't work
 23 2015-07-12 09:32:49 <volante> shower thought: has anyone thought about adding SPV mining support into bitcoin core?
 24 2015-07-12 09:37:08 <phantomcircuit> volante, spv mining is unsafe
 25 2015-07-12 09:37:09 <phantomcircuit> so
 26 2015-07-12 09:37:10 <phantomcircuit> no
 27 2015-07-12 09:37:37 <volante> yeah but it's more unsafe when people don't do it right
 28 2015-07-12 09:38:12 <volante> it's kinda like syringe disposal.  you don't necessarily condone it, but you want to make it safe if they choose to do it.  and considering a majority of the hash power is spv mining..
 29 2015-07-12 09:45:30 <phantomcircuit> volante, resources would be better spent on improving validation times
 30 2015-07-12 09:52:17 <volante> but faster validation times wouldn't have prevented the bip66 fork right?
 31 2015-07-12 09:53:03 <volante> it was caused by poor implementations of spv mining
 32 2015-07-12 09:53:28 <phantomcircuit> volante, the only reason they're doing spv mining is because of validation and propagation times
 33 2015-07-12 09:55:20 <volante> you think if validation/propagation times get low enough, they will revert their patches and go back to mining orphan blocks while they validate?
 34 2015-07-12 09:58:48 <gmaxwell> volante: it should be no slower, not at all.
 35 2015-07-12 09:59:21 <gmaxwell> volante: keep in mind, virtually all the work of validation is already done long before the block arrives.
 36 2015-07-12 10:07:48 <volante> how can it be no slower?
 37 2015-07-12 10:08:01 <volante> the closest thing i've heard of is IBLT.  has there been any progress on that?
 38 2015-07-12 10:08:58 <gmaxwell> volante: There is the block relay network protocol, which exists and is widely used. It reduces the transfer of any preforwarded transaction to ~2 bytes.
 39 2015-07-12 10:11:30 <volante> wow, 2 bytes. :)
 40 2015-07-12 10:11:41 <volante> so the miners who were spv mining, are they part of that network?
 41 2015-07-12 10:12:31 <gmaxwell> maybe, maybe not, though it turned out that the nearest hub was 200ms away from them; due to halarious internet topology.
 42 2015-07-12 10:12:50 <gmaxwell> thats being fixed.
 43 2015-07-12 10:46:00 <azariah> tip of online or cmd-line util for printing op code names from a script hex?
 44 2015-07-12 10:47:18 <azariah> script hex pretty-printer is probably the right name for it :)
 45 2015-07-12 11:12:57 <leakypat> petertodd: re the nVersion flag on an RBF able transaction; would it be possible to RBF that transaction with a non-RBF able transaction?
 46 2015-07-12 11:44:21 <JWU42> any idea on timing of releasing the 0.11 binaries ?
 47 2015-07-12 11:51:55 <sinetek> does this situation mean the whole bitcoin network  will be version 0.9.5 and up from now on?
 48 2015-07-12 11:52:15 <sinetek> ie old versions are dead
 49 2015-07-12 11:53:34 <sinetek> i used to see a _lot_ of version 0.8.x nodes in my peer list, so wondering if the node count will drop dramatically because lazy people not upgrading
 50 2015-07-12 11:55:22 <sinetek> they're all 10.1/10.2 now though.
 51 2015-07-12 12:06:55 <gmaxwell> sinetek: these kinds of questions are best asked in #bitcoin but the answer is no, old versions still work.
 52 2015-07-12 12:07:32 <gmaxwell> sinetek: one ought not mine on them; and they have whatever bugs and/or security problems they have... but they'll happily process the chain and continue working.
 53 2015-07-12 15:26:14 <PRab> I'm having trouble with the new gitian process. http://sebsauvage.net/paste/?50cd19653705d65b#qMZPnTzcgZSCaxucU/z9XFDokQsrg4+YAWjmG1pZ//0=
 54 2015-07-12 15:26:17 <PRab> Any ideas
 55 2015-07-12 15:31:29 <michagogo> You're missing two files
 56 2015-07-12 15:31:43 <michagogo> You need osslsomething and the patch for it in inputs/
 57 2015-07-12 15:31:58 <PRab> Oops, will do.
 58 2015-07-12 15:32:19 <PRab> I just figured I could keep doing the same thing I had for the other RCs
 59 2015-07-12 15:36:06 <michagogo> PRab: you can, if you built rc3
 60 2015-07-12 15:36:22 <michagogo> But the windows detached signing process was refined between rc2 and rc3
 61 2015-07-12 15:36:47 <michagogo> (I think)
 62 2015-07-12 15:44:49 <sinetek> that time when you type github.com/r/bitcoin....
 63 2015-07-12 15:48:50 <sinetek> yea lol
 64 2015-07-12 15:49:59 <michagogo> Not
 65 2015-07-12 15:49:59 <michagogo> There is
 66 2015-07-12 15:50:01 <michagogo> Not many repos
 67 2015-07-12 15:57:23 <wumpus> congrats all! 0.11.0 release announcement posted. https://bitcoin.org/en/download will be updated shortly
 68 2015-07-12 16:02:47 <kimon> All, please explain me. The transaction ed98d9f08d5d0c5e6b8abdb12b569d05a0e29847cdcec7d0d1e5602030023441 that transfer btc for my address, in my wallet "bitcoin-cli gettransaction" show "confirmations" : -1, on blockchain.info it have status "has been pruned rom our database". Will that transaction to be confirmed in future?
 69 2015-07-12 16:03:59 <sinetek> prolly wrong chan
 70 2015-07-12 16:04:14 <harding> kimon: it would be better to ask your question in #bitcoin
 71 2015-07-12 16:05:24 <Luke-Jr> wumpus: your -dev release announcement has an invalid signature O.o
 72 2015-07-12 16:06:02 <michagogo> wumpus: reddited
 73 2015-07-12 16:09:54 <harding> Luke-Jr: same here, although his signature on the SHA256SUMS.asc checked out for me.
 74 2015-07-12 16:15:15 <wumpus> Luke-Jr: bleh, I'll re-send and re-sign
 75 2015-07-12 16:15:54 <L0rd-Z3r0> hello people! I was asking myself how bitcoin wallets are communicating between each others (how the address are made and how it works etc)  , and I failed finding proper good documentation about it, and I guess you can hook me up with what I'm looking for.. ?
 76 2015-07-12 16:17:29 <jcorgan> L0rd-Z3r0: please ask in #bitcoin
 77 2015-07-12 16:17:42 <L0rd-Z3r0> ok, thanks
 78 2015-07-12 16:17:51 <L0rd-Z3r0> have a good day!
 79 2015-07-12 16:23:10 <hsmiths> wumpus: 0.11 crashes on OSX: pastebin.com/WK40Mk39
 80 2015-07-12 16:26:27 <sipa> michagogo: tweeted
 81 2015-07-12 16:34:29 <wumpus> anyone else with osx problems?
 82 2015-07-12 16:42:11 <wumpus> Luke-Jr: wtf, signature botched again on re-send, not sure what the issue is.
 83 2015-07-12 16:43:57 <wumpus> looks like a few lines get clipped at send: http://0bin.net/paste/KSYGWCyYNpFwndM9#17l5CIj3vcLyBhOQMV29491mHqI+MOY3NFZSc10o5f7
 84 2015-07-12 16:46:56 <wumpus> unicode conversion issues, wonderful
 85 2015-07-12 17:14:35 <wumpus> good signature. finally.
 86 2015-07-12 17:17:22 <jcorgan> at least you know people are checking
 87 2015-07-12 17:18:02 <wumpus> right that's very positive
 88 2015-07-12 17:22:02 <hsmiths> wumpus: new build launches ok on osx :)
 89 2015-07-12 17:22:21 <PRab> Um... All 3 announcements look like they have good signatures to me (enigmail)
 90 2015-07-12 17:22:34 <wumpus> hsmiths: great!
 91 2015-07-12 17:24:35 <wumpus> PRab: the problem was that the message is utf-8, then signed, then converted and sent as iso-8859-1. So it would only check out in the rare case that your mail clients convert to utf-8 before checking
 92 2015-07-12 17:29:22 <PRab> wumpus: Checking using mailvelope
 93 2015-07-12 17:30:09 <PRab> Yep, If it is actually supposed to be a bad signature, then both enigmail and mailvelope do the conversion that you described.
 94 2015-07-12 18:40:52 <JackH_> bip68 is merged in master right?
 95 2015-07-12 18:41:11 <JackH_> and is part of the 0.11 release as I understand
 96 2015-07-12 18:44:28 <wumpus> JackH_: it's merged mempool-only on master, it's not in any way part of 0.11
 97 2015-07-12 18:45:01 <JackH_> ahh I see wumpus
 98 2015-07-12 18:45:07 <JackH_> any plans on adding it in the future?
 99 2015-07-12 18:45:37 <PRab> Everything in master should end up in 0.12
100 2015-07-12 18:48:08 <JackH_> uh, this is interesting
101 2015-07-12 18:48:39 <sipa> what is>
102 2015-07-12 18:49:10 <JackH_> that it will be in 0.12
103 2015-07-12 18:51:00 <sipa> that's not what PRab said
104 2015-07-12 18:51:19 <sipa> he said that everything in master should end up in 0.12
105 2015-07-12 18:51:28 <sipa> BIP68 softfork is not (yet) in master
106 2015-07-12 18:51:44 <JackH_> oh
107 2015-07-12 18:53:40 <sipa> oh
108 2015-07-12 18:53:47 <sipa> it's not in mempool either
109 2015-07-12 18:54:07 <sipa> wumpus (and me) probably thought you were talking about bip65
110 2015-07-12 19:00:18 <morcos> sipa: i'm trying to follow the fee requirement for replacement in 6421.  i see why its difficult to do "right", but wouldn't a chain of free transactions anchored by a high fee dependent possibly clog up the mempool
111 2015-07-12 19:00:56 <sipa> morcos: yes...
112 2015-07-12 19:01:28 <morcos> i suppose that can only serve to lower the size of everyone's effective mempool
113 2015-07-12 19:01:28 <sipa> i'm working on an improvement which tries the last few mempool transactions, and bails out if they have too many dependencies to be useful
114 2015-07-12 19:02:24 <sipa> not optimal
115 2015-07-12 19:02:38 <sipa> but it seems to find a lot more replacements in practice
116 2015-07-12 19:05:53 <morcos> and whats the down side of purging a chain of transactions which actually has higher total fee, but lower fee rate than your new replacement?
117 2015-07-12 19:06:42 <morcos> i understand that you might then be able to fill in the extra space with lower fee stuff, but that doesn't lead to an attack, b/c as you repeat, you eventually have to keep filling up some portion with a higher fee rate
118 2015-07-12 19:07:08 <sipa> i don't follow
119 2015-07-12 19:08:16 <morcos> well, i don't understand why you can't book a low fee parent transaction just because it has a high fee child such that the total fee removed is more than the fee of the tx you're adding
120 2015-07-12 19:08:39 <sipa> book?\
121 2015-07-12 19:08:40 <morcos> s/book/boot
122 2015-07-12 19:09:08 <sipa> ok i should state the goals i think
123 2015-07-12 19:09:23 <sipa> so the limiter code aims to maximize the feerate of transactions in the mempool
124 2015-07-12 19:09:44 <sipa> however, the idea is that the fee should pay for the 'cost' of a relay, according to whatever the relay fee is
125 2015-07-12 19:10:01 <sipa> if you're able to send a transaction, that ends up at the bottom of the limited mempool
126 2015-07-12 19:10:20 <sipa> and then send another transaction which replaces with a tiny bit better feerate
127 2015-07-12 19:10:24 <sipa> you don't want to just accept it
128 2015-07-12 19:10:25 <morcos> yeah i got that part
129 2015-07-12 19:10:31 <morcos> and i agree there needs to be a delta
130 2015-07-12 19:10:39 <sipa> so you need to look at the fee of the transactions removed
131 2015-07-12 19:10:48 <morcos> i'm not sure i agree with that
132 2015-07-12 19:10:53 <sipa> (or keep track of what a transaction has replaced)
133 2015-07-12 19:11:00 <sipa> the latter is also possible, and better, but harder
134 2015-07-12 19:11:16 <morcos> i think if the feerate you have is higher (but your size is smaller), and you kick out something larger
135 2015-07-12 19:11:34 <sipa> define 'you have'
136 2015-07-12 19:11:43 <morcos> then yes you may have created some temporary space which could be filled more cheaply
137 2015-07-12 19:11:48 <morcos> but i don't think it results in an attack
138 2015-07-12 19:11:49 <sipa> no no
139 2015-07-12 19:11:59 <morcos> (the tx your considering)
140 2015-07-12 19:12:02 <sipa> the problem is that the old larger thing has been relayed by the network
141 2015-07-12 19:12:08 <sipa> something needs to pay for that
142 2015-07-12 19:12:13 <morcos> ah.. i see
143 2015-07-12 19:12:33 <sipa> otherwise you get bandwidth cost that is less than the configured feerate
144 2015-07-12 19:12:56 <sipa> one way of dealing with this is to keep track of the size of transactions a mempool entry has replaced already
145 2015-07-12 19:13:12 <sipa> and use the old-already-replaced-size when computing the fee requirement
146 2015-07-12 19:14:11 <morcos> i'm not 100% convinced by this logic
147 2015-07-12 19:14:46 <morcos> imagine you always submit transactions that are at the 2nd percentile fee rate of the mempool (but high enough to cause the bottom tx to be evicted)
148 2015-07-12 19:14:57 <morcos> isn't it fairly likely thats free relay for you?
149 2015-07-12 19:15:12 <morcos> your transaction is going to be evicted before its mined i would think?
150 2015-07-12 19:15:29 <sipa> the 2nd percentile at the bottom or the top?
151 2015-07-12 19:15:37 <morcos> 2nd meaning bottom
152 2015-07-12 19:15:53 <sipa> well you want to avoid people to be able to get free relay
153 2015-07-12 19:16:35 <morcos> i guess what i'm asking is there a way to reliably transmit transactions that are going to be relayed now, but are tenously low fee, such that they are likely to be evicted, so you haven't really paid for the relay
154 2015-07-12 19:16:53 <morcos> but maybe thats not possible....
155 2015-07-12 19:17:06 <morcos> b/c that would imply the feerate of tx's was always increasing
156 2015-07-12 19:17:31 <sipa> if you make the (utterly unrealistic) assumption that everyone deploys the same relay/replacement code, and has nearly consistent mempool of the same size, and miners do the same
157 2015-07-12 19:18:20 <sipa> then only allowing replacement when the fee delta between added and removed pays for the new transaction, results in everyone eventually paying for their relay
158 2015-07-12 19:19:59 <sipa> it is an overestimate
159 2015-07-12 19:20:06 <morcos> yeah ok, i think i'm convinced ..    but agree a few improvements if possible to stop a low-fee/free parent of an expensive child stopping any replacment from happening would be good.  you said you're going to try the last few, would it make sense to randomly try something from the bottom 10%
160 2015-07-12 19:20:32 <sipa> i have some heuristics that work pretty well now, it seems
161 2015-07-12 19:20:51 <sipa> though obviously pre-combined parents-with-children would make it a lot better
162 2015-07-12 19:20:59 <sipa> works in ~50us or so
163 2015-07-12 19:21:58 <sipa> for example, you can stop when you hit a transaction-to-be-removed whose feerate is higher than the tx you're adding
164 2015-07-12 19:22:11 <morcos> ok great, looking forward to it.  thanks for putting everyone on the same page for this.  its a great improvement.
165 2015-07-12 19:22:40 <sipa> this dos attack is very useful for benchmarking my code :)
166 2015-07-12 19:23:03 <morcos> ha, just don't run with -checkmempool!
167 2015-07-12 19:23:18 <sipa> and adding a pto->SendMessage("mempool") in the connection code makes your mempool fill very quickly
168 2015-07-12 19:24:14 <morcos> i didn't even know about that
169 2015-07-12 19:25:27 <morcos> oh btw, random question about checkmempool, you use a const_cast on pcoins.   is that only safe b/c there is no call to flush?  is that worth commenting?
170 2015-07-12 19:26:17 <sipa> yeah, should be documented i think
171 2015-07-12 19:55:29 <deego> reading this. http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008659.html  what is NACK?
172 2015-07-12 19:56:10 <sinetek> not ack.
173 2015-07-12 19:56:58 <deego> ah
174 2015-07-12 19:58:02 <sinetek> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-December/006971.html
175 2015-07-12 19:58:57 <deego> sinetek: thanks
176 2015-07-12 20:00:37 <sinetek> np
177 2015-07-12 21:21:23 <Luke-Jr> sinetek: NACK is actually much stronger than !ACK
178 2015-07-12 21:21:49 <Luke-Jr> deego: https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md#pull-request-terminology
179 2015-07-12 21:24:00 <deego> ah
180 2015-07-12 21:31:26 <phantomcircuit> sipa, closed my pr on the mempool stuff in favor of 6421
181 2015-07-12 21:31:55 <phantomcircuit> i still think the boost multiindex stuff is going to end up being a mistake
182 2015-07-12 21:32:01 <phantomcircuit> but not strongly enough to oppose it
183 2015-07-12 21:33:34 <sipa> phantomcircuit: what problems do you expect?
184 2015-07-12 21:36:00 <phantomcircuit> sipa, complexity and additional reliance on boost
185 2015-07-12 21:36:08 <phantomcircuit> but i guess we're fairly married to boost at this point anyways
186 2015-07-12 21:45:05 <sipa> phantomcircuit: i think multiindex is very elegant... specify indexes and everything automatically remains consistent
187 2015-07-12 21:45:18 <sipa> phantomcircuit: i agree with the boost reliance...
188 2015-07-12 21:46:37 <phantomcircuit> sipa, if the decision to relay was decoupled from mempool acceptance it would be much easier to do this all
189 2015-07-12 21:46:51 <phantomcircuit> since mempool cleanup could simple be running in the background
190 2015-07-12 21:47:29 <sipa> perhaps that is true
191 2015-07-12 21:48:23 <gmaxwell> phantomcircuit: Most of what we use in boost is in C++11.
192 2015-07-12 21:48:45 <phantomcircuit> oh i guess i didn't make that clear
193 2015-07-12 21:48:57 <phantomcircuit> the multiindex stuff isn't in c++11 (it's not right?)
194 2015-07-12 21:49:04 <phantomcircuit> so this weds us to boost even more so
195 2015-07-12 21:49:27 <sipa> indeed
196 2015-07-12 21:49:31 <sipa> it is not
197 2015-07-12 21:49:44 <phantomcircuit> but well it would be nice to deploy this reasonably soon
198 2015-07-12 21:50:01 <sipa> it's always possible to reimplement some specialized index for this
199 2015-07-12 21:50:16 <sipa> it's not too hard, just a lot of duplicated work
200 2015-07-12 21:50:24 <phantomcircuit> well if we decouple the relay/mempool acceptance it's pretty easy to do
201 2015-07-12 21:50:32 <phantomcircuit> nMinFeeRateForAcceptance
202 2015-07-12 21:50:41 <phantomcircuit> which is updated everytime the cleanup routine runs
203 2015-07-12 21:51:16 <phantomcircuit> otoh spikes of spam would put you over the limit so maybe not
204 2015-07-12 22:05:14 <phantomcircuit> huh
205 2015-07-12 22:05:18 <phantomcircuit> setAddrKnown was removed?
206 2015-07-12 22:05:55 <Luke-Jr> sipa: wait, does it fix the broken priority calculation in CTxMemPoolEntry?
207 2015-07-12 22:07:22 <phantomcircuit> ah yes
208 2015-07-12 22:11:32 <sipa> Luke-Jr: the mempool limiting stuff ignores priority
209 2015-07-12 22:11:57 <Luke-Jr> that's going to make the problems worse then
210 2015-07-12 22:12:04 <sipa> how so?
211 2015-07-12 22:12:25 <Luke-Jr> priority is pretty much the most useful anti-spam in the reference code right now
212 2015-07-12 22:12:45 <sipa> ignored is probably the wrong word
213 2015-07-12 22:12:53 <phantomcircuit> Luke-Jr, the goal is to prevent the mempool from ballooning to insanity sizes
214 2015-07-12 22:13:09 <Luke-Jr> phantomcircuit: doing it by dropping the ones you should keep is the wrong way :P
215 2015-07-12 22:13:10 <phantomcircuit> the relay rules are still largely the same modulo insanity sizes mempool
216 2015-07-12 22:13:12 <phantomcircuit> sized*
217 2015-07-12 22:13:40 <phantomcircuit> Luke-Jr, you want your mempool to look like what you expect to get mined
218 2015-07-12 22:13:51 <phantomcircuit> which means strict feerate ordering
219 2015-07-12 22:14:02 <sipa> Luke-Jr: if a transaction x is received, we look for a set of transactions y to evict to make place for it; the lower the feerate, the higher the chance for eviction
220 2015-07-12 22:14:04 <Luke-Jr> phantomcircuit: no, because that shouldn't be what you expect
221 2015-07-12 22:14:27 <phantomcircuit> Luke-Jr, i expect miners to be maximally rational in the short term
222 2015-07-12 22:14:30 <Luke-Jr> sipa: so you're evicting high priority transactions you want, in exchange for low-priority high-fee spam..
223 2015-07-12 22:14:37 <phantomcircuit> and nothing more
224 2015-07-12 22:15:14 <sipa> Luke-Jr: however, the new transactions need to pay fee for the transactions being evicted
225 2015-07-12 22:15:49 <phantomcircuit> sipa, he's arguing that priority is a better metric than feerate
226 2015-07-12 22:16:07 <phantomcircuit> even if we assume that's true
227 2015-07-12 22:16:19 <phantomcircuit> priority has to be recalculated when a new block is found
228 2015-07-12 22:16:23 <phantomcircuit> which makes it much less useful
229 2015-07-12 22:16:55 <Luke-Jr> sipa: these are all very logical rules for preventing relay DoS amplification attacks, but not very good rules for getting legit transactions relayed/mined
230 2015-07-12 22:17:40 <sipa> define legit
231 2015-07-12 22:17:47 <Luke-Jr> real people trying to use bitcoin
232 2015-07-12 22:19:56 <sipa> priority is already irrelevant for the majority of transactions
233 2015-07-12 22:20:09 <sipa> i only rarely see a free transaction being relayed
234 2015-07-12 22:20:15 <Luke-Jr> …
235 2015-07-12 22:21:13 <sipa> i think the correct way to deal with this is to have a modified 'fee' calculation that takes priority into account
236 2015-07-12 22:21:27 <sipa> rather than the non-functioning priority area we have now
237 2015-07-12 22:21:43 <Luke-Jr> that would probably be an improvement to policy, at least
238 2015-07-12 22:21:46 <sipa> which is hard to implement, prevents better performing code, and is actually hardly used
239 2015-07-12 22:43:20 <freewil> BlueMatt: any chance of updating the 1024-bit signing key for the bitcoin ppa?
240 2015-07-12 23:14:55 <phantomcircuit> gmaxwell, setAddrKnown was replaced with a bloomfilter
241 2015-07-12 23:15:18 <phantomcircuit> does it seem reasonable to just slowly set random bits in the bloom filter to zero instead of clearing the entire thing?
242 2015-07-12 23:16:22 <phantomcircuit> sipa, ^
243 2015-07-12 23:16:24 <phantomcircuit> same question
244 2015-07-12 23:29:03 <sfultong> how come it seems like all the pgp signatures were changed right before 0.11 ?
245 2015-07-12 23:29:33 <Luke-Jr> michagogo: bad link https://www.reddit.com/r/Bitcoin/comments/3d0uhg/bitcoin_core_version_0110_released/ct0yejm
246 2015-07-12 23:29:48 <gmaxwell> sfultong: a month-ish before. The new key is signed by the old one.
247 2015-07-12 23:30:01 <Luke-Jr> sfultong: all? mine wasn't.
248 2015-07-12 23:30:08 <sfultong> err, heh, nevermind, not all
249 2015-07-12 23:30:27 <sfultong> I should pgp better
250 2015-07-12 23:30:48 <sfultong> gmaxwell: where can I see the signing?
251 2015-07-12 23:31:00 <gmaxwell> sfultong: run gpg --list-sigs <keyid>
252 2015-07-12 23:31:16 <sfultong> cool, thanks
253 2015-07-12 23:54:01 <sfultong> can someone update Wladimir J. van der Laan's key on bitcoin.org, please?
254 2015-07-12 23:54:38 <gmaxwell> sfultong: huh? its updated.
255 2015-07-12 23:55:46 <Luke-Jr> sfultong: his new key is *just* for releases; the previous key is still his main one
256 2015-07-12 23:55:46 <sfultong> hmm... it's ssl, so it couldn't be cached, could it?
257 2015-07-12 23:55:53 <sfultong> oh!
258 2015-07-12 23:56:01 <sfultong> sorry, I was confused
259 2015-07-12 23:56:17 <sfultong> it'd be nice to have that up on bitcoin.org as well
260 2015-07-12 23:59:40 <phantomcircuit> gmaxwell, plz2comment #5989