1 2015-07-11 10:41:59 <petertodd> leakypat: haha, that's seriously awesome, especially the way you literally turned on the miner!
  2 2015-07-11 10:44:31 <leakypat> Hehe
  3 2015-07-11 10:45:17 <petertodd> leakypat: https://twitter.com/petertoddbtc/status/619819667612434432
  4 2015-07-11 10:46:41 <leakypat> Hehe nice
  5 2015-07-11 10:50:17 <petertodd> leakypat: btw, change your twitter name to "ninki wallet" - couldn't find your twitter account for that tweet
  6 2015-07-11 10:50:35 <petertodd> leakypat: (what currently is just "Ninki")
  7 2015-07-11 10:59:09 <leakypat> Ok, changed it, actually @shibuyashadows is my main tweeting account
  8 2015-07-11 13:57:42 <jonasschnelli> sipa: i think your #6421 misses an implementation / template for ‘IncrementalDynamicUsage(const std::map<COutPoint, CInPoint>&)
  9 2015-07-11 13:59:24 <sipa> yes, i'm fixing a bunch of things
 10 2015-07-11 13:59:43 <sipa> working on a really low-power laptop, and actually testing compilation takes an age :)
 11 2015-07-11 14:24:26 <s1w> it takes a whole age?
 12 2015-07-11 14:24:28 <s1w> that's quite a whiel
 13 2015-07-11 14:24:28 <s1w> while, even
 14 2015-07-11 14:30:52 <jgarzik> sipa, Your mempool-limit patch will drop too-low-fee TXs, and not relay them, assuming the mempool is already at its cap?
 15 2015-07-11 14:30:53 <jgarzik> (I hope yes)
 16 2015-07-11 14:31:55 <sipa> indeed
 17 2015-07-11 14:32:38 <sipa> (or raplace the lowest fees ones in the mempool already, if the new ones pays enough fees for their cost too)
 18 2015-07-11 14:34:24 <jonasschnelli> sipa: how about own wallet transactions with 6421?
 19 2015-07-11 14:34:58 <sipa> i thought phantomcircuit determined that wasn't a problem
 20 2015-07-11 14:35:15 <jonasschnelli> sry. didn't followed that discussion. But i also agree that this is lowprio
 21 2015-07-11 14:38:08 <jgarzik> good
 22 2015-07-11 14:38:08 <jgarzik> sipa, right right
 23 2015-07-11 14:38:45 <sipa> now, the rule for determining how much 'extra' fee those new transactions need to account for the replaced ones, is determined by the relay fee
 24 2015-07-11 14:39:05 <sipa> so we still need something that adjusts the relay fee if the mempool is growing too large imho
 25 2015-07-11 14:41:02 <jonasschnelli> started a graph with sipa 6410 pr: http://bitcoin.jonasschnelli.ch/charts/mempool6410/ (not much there right now, just started, mempool is filling up).
 26 2015-07-11 14:57:21 <jgarzik> sipa, I'm not sure I understand that last part.  If bitcoind drops-and-doesnt-relay transactions with fees too low to get into the mempool, it would seem to naturally create a floating relay fee?
 27 2015-07-11 14:58:10 <jgarzik> assuming a full mempool
 28 2015-07-11 15:04:02 <sipa> jgarzik: i guess the effect is that the effective "fee necessary for relaying" becomes floating with this PR, but there is still is a meaningful minrelayfee variable
 29 2015-07-11 15:04:27 <jgarzik> sipa, agree
 30 2015-07-11 15:04:28 <sipa> jgarzik: and the latter is used for determining how much a transaction B that replaces a transaction A should be to cover A's size
 31 2015-07-11 15:05:19 <sipa> and i'm saying that we still want something to adjust that minrelayfee variable, to avoid spamming the network with transactions that continuously replace eachother by only incrementing the fee slightly in every step
 32 2015-07-11 15:06:59 <jgarzik> sipa, what did you think about the high water/low water approach in #6402?    My thought for long term was complex:  (1) mempool cap.  If at cap, new TX pushes out others, or gets dropped off the low end.   Of course, this is bursty with block confirmation clearing out swaths of mempool.   (2) high water / low water as in #6402.  Makes behavior less bursty per-block.  Mempool cap becomes an absolute limit, but mempool does not remain full all
 33 2015-07-11 15:06:59 <jgarzik> the time with #2.   (3) mempool janitor to remove too-old transactions.
 34 2015-07-11 15:07:42 <jgarzik> Thus #2 w/ floating relay fee becomes the main actor.  Mempool cap enables burst survival in a sane way.  Janitor expires garbage miners ignore.
 35 2015-07-11 15:08:08 <sipa> i haven't looked at the code, but the approach seems reasonable
 36 2015-07-11 15:08:29 <sipa> indeed, you want something that keeps the 'effective' relay fee somewhat continuous
 37 2015-07-11 15:08:43 <sipa> rather than dropping every time a block is mined
 38 2015-07-11 15:11:47 <sipa> jgarzik: so yes, i don't think 6421 is a full solution
 39 2015-07-11 15:13:31 <jgarzik> sipa, with #6402, the relay fee drops to minimum if below "low water" line.  If mempool rises above "high water", relay fee increased to lowest-of-top-half, and mempool said to be in "draining" state.
 40 2015-07-11 15:13:52 <jgarzik> If mempool remains above high water, relay fee continually adjusted
 41 2015-07-11 15:14:08 <jgarzik> though presumably that only happens in bursts
 42 2015-07-11 15:14:14 <jgarzik> based on actual traffic
 43 2015-07-11 15:14:36 <jgarzik> I think it works very well w/ a mempool cap - complementary
 44 2015-07-11 15:14:43 <jgarzik> IMO you want both
 45 2015-07-11 15:14:56 <sipa> you could default to lowwater = cap/3, highwater = 2*cap/3 or something
 46 2015-07-11 15:16:12 <jgarzik> sipa, yep
 47 2015-07-11 15:17:47 <sipa> a very simple effective_relay_fee = minrelayfee * (cap - lowwater) / (usage - lowwater) would also work
 48 2015-07-11 15:18:23 <sipa> though it's better to use feedback from fees actually used in the mempool
 49 2015-07-11 15:19:02 <jgarzik> agree w/ latter
 50 2015-07-11 15:19:08 <sipa> and just increasing relay fee is not enough, because a higher relay fee makes it harder to replace transactions in the mempool
 51 2015-07-11 15:19:21 <sipa> it should aim to be something that is continuous
 52 2015-07-11 15:19:38 <sipa> perhaps a long-term average of some percentile of the mempool
 53 2015-07-11 15:21:41 <jgarzik> Though I agree it is a much lower merge priority than these others, having a janitor sweeping out never-confirming transactions is important for keeping a sane idea of what fees truly are
 54 2015-07-11 15:23:13 <jgarzik> Has anyone yet figured out a good method for SPV[ish] clients determining a good fee to pay?
 55 2015-07-11 15:23:15 <Lightsword> sipa, looks like seed.bitcoin.sipa.be is getting flagged by certsi.es as a Fast Flux botnet or something like that, PM’d details
 56 2015-07-11 15:23:27 <sipa> Lightsword: known issue...
 57 2015-07-11 15:23:30 <jgarzik> Lightsword, unavoidable
 58 2015-07-11 15:23:51 <Lightsword> anyway to get them to whitelist that?
 59 2015-07-11 15:24:10 <jgarzik> Bitcoin is basically a benevolent autonomous botnet ;p
 60 2015-07-11 15:24:22 <venzen> sipa: you mention keeping a longterm average of some percetile of the mempool...
 61 2015-07-11 15:25:08 <venzen> basically, keeping track of mempool trend
 62 2015-07-11 15:25:23 <sipa> jgarzik: or we could just use the feerate estimated by the fee estimator
 63 2015-07-11 15:25:46 <sipa> but i don't know much about that
 64 2015-07-11 15:25:58 <venzen> there is a technique in chart analysis that uses two averages: one longterm, and one shortterm
 65 2015-07-11 15:26:12 <venzen> where they cross over there is usually a change in trend
 66 2015-07-11 15:26:22 <venzen> for what its worth..
 67 2015-07-11 15:30:46 <venzen> how can i see what's in my pruning node's mempool, anyone?
 68 2015-07-11 15:31:04 <jgarzik> venzen, getrawmempool
 69 2015-07-11 15:31:09 <jgarzik> getmempoolinfo
 70 2015-07-11 15:31:16 <venzen> thank jgarzik
 71 2015-07-11 15:32:24 <jgarzik> Youch.  Current run of bitcoind is 13 hours without a single connection to the network.
 72 2015-07-11 15:32:36 <jgarzik> (I run with DNS seeding disabled; no nodes since startup)
 73 2015-07-11 15:32:53 <jgarzik> I wonder if recent 'getaddr' changes impacted this.
 74 2015-07-11 15:36:38 <wumpus> huh? what version? a problem with the built-in seeds?
 75 2015-07-11 15:37:14 <jgarzik> wumpus, master/HEAD
 76 2015-07-11 15:37:19 <jgarzik> as of 24 hours ago
 77 2015-07-11 15:37:23 <sipa> ouch
 78 2015-07-11 15:37:56 <jgarzik> wumpus, I have a nicely full peers.dat - not relying on built-in seeds
 79 2015-07-11 15:38:00 <wumpus> I'm sure I'd tested it with an empty peers.dat and no DNS seeding.
 80 2015-07-11 15:38:02 <jgarzik> still, 13 hours without a single connection
 81 2015-07-11 15:38:08 <jgarzik> full peers.dat, not empty
 82 2015-07-11 15:38:22 <jgarzik> we need to expire garbage out of addrman - old problem...
 83 2015-07-11 15:38:33 <sipa> maybe a full peers.dat is worse than an empty one...
 84 2015-07-11 15:38:39 <wumpus> figures
 85 2015-07-11 15:38:41 <jgarzik> indeed
 86 2015-07-11 15:38:45 <sipa> iirc i did test that when making the latest addrman changes
 87 2015-07-11 15:39:22 <jgarzik> 2015-07-11 15:33:46 Loading addresses from DNS seeds (could take a while)
 88 2015-07-11 15:39:23 <jgarzik> 2015-07-11 15:38:22 connect() to 24.138.49.181:8333 failed after select(): No route to host (113)
 89 2015-07-11 15:39:30 <jgarzik> Just turned on DNS seeding, still unlucky ;-)
 90 2015-07-11 15:39:49 <jgarzik> Let's see if a shower fixes things
 91 2015-07-11 15:40:17 <jgarzik> The "full peers.dat problem" is even more acute on testnet, with DNS seeding disabled
 92 2015-07-11 15:44:29 <wumpus> on testnet finding peers is harder. But I've never had problems getting any connections at all, even without dns seeding. Was this a really old peers.dat?
 93 2015-07-11 15:45:15 <wumpus> if it had any recent connections in earlier sessions I'd assume it remembers them and retries them, or something must be very wrong with the code
 94 2015-07-11 15:53:27 <wumpus> still get "P2P peers available. Skipped DNS seeding." on my nodes
 95 2015-07-11 15:58:14 <jgarzik> 2015-07-11 15:57:48 connect() to [2a01:e35:87ad:a610:b8e7:dac2:50bc:d896]:8333 failed: Network is unreachable (101)
 96 2015-07-11 15:58:37 <jgarzik> DNS seeding enabled - full peers.dat - 25 minutes with no peers
 97 2015-07-11 15:59:09 <jgarzik> wumpus, not "really old" peers.dat - the node was working and active days ago, before my trip, when I shut it down.
 98 2015-07-11 15:59:50 <wumpus> can you try stopping the node, moving the peers.dat out of the way (not deleting it!), then restarting it? that would distinguish between a peers.dat problem and weird network issues
 99 2015-07-11 16:00:54 <jgarzik> wumpus, heh, just deleted, turned on DNS seeding, let's see...
100 2015-07-11 16:04:32 <sipa> wtf
101 2015-07-11 16:04:33 <sipa> /usr/include/boost/multi_index/ordered_index.hpp:1399:10: error: ‘boost::Q_FOREACH’ has not been declared boost::foreach::tag)
102 2015-07-11 16:04:58 <sipa> qt apparently #defines the foreach word?
103 2015-07-11 16:06:01 <jgarzik> interesting.  bitcoind debug.log is 85% complaints about IPv6 addresses.  Just 2 IPv4 addresses tried so far.
104 2015-07-11 16:07:06 <jgarzik> 30 IPv6 addresses tried, 2 IPv4 addresses tried
105 2015-07-11 16:07:10 <jgarzik> >85%
106 2015-07-11 16:07:25 <jgarzik> with just DNS seed data + built-in seeds
107 2015-07-11 16:10:41 <jgarzik> after 10 minutes, zero connections, 4 IPv4 addresses tried
108 2015-07-11 16:16:17 <jgarzik> stopping after 15 minutes with no connections (empty peers.dat + built-in seed + DNS seed)
109 2015-07-11 16:18:08 <jgarzik> bitcoind should have a way of detecting consistent IPv6 failure and skipping remaining IPv6 addresses, perhaps
110 2015-07-11 16:18:39 <jgarzik> also wonder if addrman buckets are somehow biased towards IPv6
111 2015-07-11 16:20:03 <wumpus> but is that the problem? if you do -onlynet=ipv4, it's solved?
112 2015-07-11 16:20:05 <aschildbach> Q: If an unconfirmed transaction has one of its outputs spent (by another tx), will it have any "confirmation penalty" or "propagation penalty" compared to if nothing would build on it?
113 2015-07-11 16:20:54 <wumpus> aschildbach: should make no difference, unless CPFP is used, in which case the parent tx is prioritized
114 2015-07-11 16:21:15 <aschildbach> Thanks that's what I expected.
115 2015-07-11 16:22:21 <aschildbach> I just wonder why txns confirm so unpredictably.
116 2015-07-11 16:22:37 <sipa> wumpus: any suggested solution? seems you just can't include multi_index_contain and qt foreach headers in the same file...
117 2015-07-11 16:22:55 <jgarzik> wumpus, a fair question.  restarting with -onlynet=ipv4
118 2015-07-11 16:23:22 <jgarzik> appears to be just sitting there -- I wonder if someone changes the select() or IPv4 connect() code recently?
119 2015-07-11 16:23:31 <sipa> i recently saw a bug report about a node incorrectly determining it has ipv6 capabilities with only a linklinked address
120 2015-07-11 16:23:32 <jgarzik> i.e. long connection timeouts or somesuch
121 2015-07-11 16:23:45 <sipa> jgarzik: you have tor?
122 2015-07-11 16:23:51 <jgarzik> sipa, no
123 2015-07-11 16:23:56 <jgarzik> not on this node anyway
124 2015-07-11 16:24:10 <sipa> default timeout should be 5s
125 2015-07-11 16:24:11 <sipa> iirc
126 2015-07-11 16:24:34 <wumpus> sipa: what error do you get?
127 2015-07-11 16:25:14 <jgarzik> Gotta run.  Leaving bitcoind running in this mode.  Peers.dat is "fresh" (contains 2 DNS seed runs)   DNS seeding enabled.  No connections so far after 5 minutes.
128 2015-07-11 16:25:42 <sipa> wumpus: scroll back 21 minutes
129 2015-07-11 16:27:57 <wumpus> sipa: qt indeed #defines foreach
130 2015-07-11 16:28:18 <sipa> maybe an #undef foreach ?
131 2015-07-11 16:29:08 <wumpus> or we need to define QT_NO_KEYWORDS, and use Q_FOREACH instead of foreach
132 2015-07-11 16:29:51 <wumpus> hm although that may influence other qt "keywords" as well, unsure
133 2015-07-11 16:30:14 <wumpus> right it  would break 'signal' and 'slot' too
134 2015-07-11 16:30:27 <wumpus> so yes, undefining foreach sounds like the least harmful solution...
135 2015-07-11 16:33:50 <wumpus> looking at the qt headers there is no way to avoid just the definition of 'foreach'
136 2015-07-11 16:36:24 <wumpus> ideally we could avoid including both in one compilation unit
137 2015-07-11 16:36:28 <sipa> undefining it doesn't seem to work
138 2015-07-11 16:36:51 <wumpus> you're undefining it just before the include of the boost header?
139 2015-07-11 16:36:56 <sipa> yes
140 2015-07-11 16:37:01 <sipa> oh
141 2015-07-11 16:37:04 <sipa> we're actually using foreach in our code
142 2015-07-11 16:37:06 <wumpus> because qt is sneaky and may keep redefining it
143 2015-07-11 16:37:12 <wumpus> yes
144 2015-07-11 16:37:17 <sipa> yeah, then undef
145 2015-07-11 16:37:20 <sipa> won't work!
146 2015-07-11 16:37:20 <wumpus> but that's easily replaced with Q_FOREACH
147 2015-07-11 16:37:23 <sipa> ok
148 2015-07-11 16:40:56 <sipa> still doesn't work
149 2015-07-11 16:40:57 <sipa> ugh
150 2015-07-11 16:41:50 <wumpus> should at least change the error?
151 2015-07-11 16:42:03 <sipa> yeah
152 2015-07-11 16:45:29 <sipa> there are still many foreaches left
153 2015-07-11 16:49:01 <sipa> n/usr/include/boost/multi_index/ordered_index.hpp
154 2015-07-11 16:49:06 <sipa> from qt/clientmodel.cpp:8:
155 2015-07-11 16:49:06 <sipa> /usr/include/boost/multi_index/ordered_index.hpp:1399:10: error: ‘boost::foreach’ has not been declared
156 2015-07-11 16:49:07 <wumpus> cd src/qt; for x in *.cpp; do sed -i s/foreach/Q_FOREACH $x; done   :p
157 2015-07-11 16:49:09 <sipa> boost::foreach::tag)
158 2015-07-11 16:49:15 <sipa> still doesn't work
159 2015-07-11 16:49:18 <sipa> i don't understand
160 2015-07-11 16:49:37 <wumpus> oh, it still complains in the boost header, bleh
161 2015-07-11 16:49:56 <wumpus> but this is about *boost::foreach*
162 2015-07-11 16:50:25 <wumpus> eh wait, no, BOOST_FOREACH, never mind
163 2015-07-11 16:51:35 <wumpus> the error used to be: error: ‘boost::Q_FOREACH’  not found
164 2015-07-11 16:51:39 <wumpus> so this is a step further
165 2015-07-11 16:51:54 <wumpus> but what isboost::foreach?!
166 2015-07-11 16:52:28 <sipa> probably some namespace/class involved in the implementation of BOOST_FOREACH?
167 2015-07-11 16:53:19 <wumpus> likely. but it never gave a problem before, even though we use BOOST_FOREACH and qt's foreach in the same code
168 2015-07-11 16:54:12 <sipa> i think the problem is including some of boost's foreach code _while_ qt foreach is defined
169 2015-07-11 16:54:53 <wumpus> so - the other solution would be to define QT_NO_KEYWORDS in the build system, but that also means replacing slots with QT_SLOTS and signals with QT_SIGNALS and emit with QT_EMIT.... (and maybe others)
170 2015-07-11 16:55:11 <wumpus> sipa: right - as long as it is consistently defined there is no problem, only if some parts are defined with and some without
171 2015-07-11 16:55:29 <wumpus> sipa: so as long as qt headers are before boost headers it should work
172 2015-07-11 16:56:36 <wumpus> (as long as "qglobal.h" is included, indirectly or directly, before any boost headers, that is. Then all uses of foreach will be replaced with Q_FOREACH and no one notices)
173 2015-07-11 16:56:37 <sipa> until boost adds a non-headers-only boost foreach
174 2015-07-11 16:56:50 <sipa> and now it tries to resolve boost::q_foreach::something
175 2015-07-11 16:58:36 <sipa> another way would be a '#define foreach foreach'
176 2015-07-11 16:58:48 <sipa> which prevents qt from redefining it
177 2015-07-11 16:59:14 <wumpus> yeah
178 2015-07-11 16:59:43 <sipa> ok, pushed working code
179 2015-07-11 16:59:46 <sipa> but it's ugly
180 2015-07-11 17:08:22 <presstab> what RPC call will return the current coin supply for the current block height?
181 2015-07-11 17:10:23 <harding> presstab: are you talking about gettxoutsetinfo
182 2015-07-11 17:10:35 <wumpus> presstab: not sure what you mean with coin supply, but you can get some global unspent stats using gettxoutsetinfo
183 2015-07-11 17:10:48 <wumpus> harding: heh
184 2015-07-11 17:15:23 <presstab> harding: yes that has what I am looking for in the "total_amount" ty sir
185 2015-07-11 17:18:17 <Luke-Jr> hmm, realistically, all miners are "SPV mining" using stratum.. it's just a question of who people trust for valid templates
186 2015-07-11 17:23:45 <evoskuil> Luke-Jr: certainly, the difference in trust models is all about where is the trust boundary (i.e. not the code), same with any wallet.
187 2015-07-11 17:29:28 <GMP> hi, just noticed HackingTeam 400GB dump contains their source code for bitcoin wallet stealing for some platforms
188 2015-07-11 17:30:48 <GMP> git/core-linux.git core/src/module_money.c
189 2015-07-11 17:31:26 <GMP> may be worth investigating, or maybe not
190 2015-07-11 17:31:38 <wumpus> GMP: yes. nothing special there, though, it just grabs the wallet from the standard location and uploads it
191 2015-07-11 17:32:01 <wumpus> GMP: same as other crimeware
192 2015-07-11 17:32:39 <billotronic> and those who are aware of the dump most likely already could code something like that anyways. moot point
193 2015-07-11 17:35:05 <GMP> ok, i noticed overall level of their tools isn't that much impressive. and 0days come probably from external sources
194 2015-07-11 17:41:08 <wumpus> indeed - software wallets can be compromised if one gets access to the execution environment of the user - a hardware wallet would provide better security
195 2015-07-11 17:41:36 <wumpus> s/would/could, those could be exploitable too but you'd expect it to at least put up another barrer...
196 2015-07-11 17:45:53 <GMP> air gap, if deployed early, could provide sufficient level of security
197 2015-07-11 17:45:58 <GMP> too
198 2015-07-11 17:46:29 <wumpus> right, that too
199 2015-07-11 17:47:12 <GMP> early = before some generic execution enviroment compromised for that specific task
200 2015-07-11 17:58:27 <Apocalyptic> what was the reason behind disabling most bitwise logic opcodes ?
201 2015-07-11 18:02:59 <GMP> i may be wrong, but i remember initial implementation was incorrect/inconsistent when operand sizes were different
202 2015-07-11 18:13:16 <GMP> just checked, there is no evidence supporting my statement^
203 2015-07-11 18:18:06 <Apocalyptic> As far as I know, most opcodes have been disabled in order to prevent DOS, either by overflowing the allocated stack size or by performing time consuming operations resulting in an unreasonable verification time, but bitwise logic instructions don't strike me as belonging to either of those categories
204 2015-07-11 18:25:05 <GMP> there might be an issue with resizing negative integers, not sure
205 2015-07-11 18:37:36 <sipa> Apocalyptic: ask satoshi
206 2015-07-11 18:46:38 <michagogo> Apocalyptic: maybe "he wasn't sure his code was perfect" or something
207 2015-07-11 18:46:57 <michagogo> 19:20:54 <wumpus> aschildbach: should make no difference, unless CPFP is used, in which case the parent tx is prioritized <-- Well, not necessarily prioritized
208 2015-07-11 18:47:27 <aschildbach> michagogo: Thanks.
209 2015-07-11 18:47:29 <aschildbach> Yes but it can never be penalized, right?
210 2015-07-11 18:47:52 <michagogo> Child
211 2015-07-11 18:47:52 <michagogo> Nodes using CPFP will be smart about calculating the benefits of confirming the parent to be able to confirm the chile
212 2015-07-11 18:48:24 <michagogo> So afaik, it figures out how many bytes and fees they are together, and if it's worthwhile to confirm them
213 2015-07-11 18:48:56 <michagogo> aschildbach: I would assume not, that the parent is still considered on its own without the child, but I don't actually know that
214 2015-07-11 18:50:04 <sipa> CPFP is hard (impossible) to implement perfectly in an efficient way
215 2015-07-11 18:50:17 <sipa> especially as you can have dependencies that depend on multiple unconfirmed parents
216 2015-07-11 18:50:47 <sipa> so it may well be the case that sometimes, actual CPFP implementation would indeed penalize an unconfirmed transaction for having a low-fee child
217 2015-07-11 18:52:36 <Luke-Jr> sipa: my implementation does not AFAIK
218 2015-07-11 18:52:55 <sipa> ok, possibl
219 2015-07-11 18:52:57 <aschildbach> sipa: Hmm that would be bad, as you could torpedo pay-to-many transactions where you are one of the recipients.
220 2015-07-11 18:56:24 <Luke-Jr> basically I just treat the child txns as if they were larger, and include the parents if the child is otherwise to be included first; but the parent still has its own entry on its own
221 2015-07-11 18:56:24 <Luke-Jr> (which also triggers a resorting of its children if it gets included first)
222 2015-07-11 18:56:25 <sipa> ok
223 2015-07-11 18:56:25 <sipa> seems reasonable
224 2015-07-11 18:57:58 <aschildbach> I'm thinking about supporting CPFP in Bitcoin Wallet. Do I understand right that it's ok to just send one output to myself?
225 2015-07-11 18:58:06 <aschildbach> And it can also be the change output? So basically it works for both incoming and outgoing payments.
226 2015-07-11 19:00:40 <aschildbach> Luke-Jr: ^
227 2015-07-11 19:02:45 <Luke-Jr> aschildbach: yes, but not as well as RBF obviously
228 2015-07-11 19:06:39 <aschildbach> Luke-Jr: I thought RBF only works if I have the keys for sending, so it won't work for the recipient, no?
229 2015-07-11 19:07:23 <GMP> RBF also needs support from relay nodes
230 2015-07-11 19:10:29 <Luke-Jr> aschildbach: right
231 2015-07-11 19:10:31 <Luke-Jr> GMP: so does CPFP
232 2015-07-11 19:10:53 <Luke-Jr> except no code is written to do CPFP relay :P
233 2015-07-11 19:15:33 <aschildbach> Luke-Jr: So CPFP is the only option for Bitcoin Wallet. Users have most trouble with others paying not enough fee. The own fee is right, after app updates.
234 2015-07-11 19:16:14 <aschildbach> The relay problem could be worked around by posting the txns to supporting miners directly.
235 2015-07-11 19:16:51 <Luke-Jr> miners have relay policies too :P
236 2015-07-11 19:17:55 <aschildbach> Luke-Jr: Sure, /supporting/ miners.
237 2015-07-11 19:18:32 <Luke-Jr> aschildbach: no CPFP relay code = supporting miners use the same relay code as anyone else
238 2015-07-11 19:19:55 <aschildbach> Ok maybe. They only need to /mine/ the CPFP transactions, not strictly required to relay them.
239 2015-07-11 19:21:29 <Luke-Jr> relay = accept to mempool
240 2015-07-11 19:21:58 <Luke-Jr> it's a solvable problem, but not one code exists for today
241 2015-07-11 19:22:44 <aschildbach> So are you saying there are no miners who support CPFP? I heard at least one mining pool does. (~5%)
242 2015-07-11 19:24:06 <Luke-Jr> aschildbach: only for mining policy, not for relay policy
243 2015-07-11 19:24:29 <aschildbach> Ok, good. As I said they only need to mine, not to relay.
244 2015-07-11 19:24:29 <Luke-Jr> so the parent must at least satisfy the relay policy, before it will be considered for CPFP
245 2015-07-11 19:25:13 <aschildbach> Yes, the txns I am talking about generally do.
246 2015-07-11 19:25:30 <aschildbach> Fee is 0.01 mBTC/KB or above.
247 2015-07-11 19:26:13 <Luke-Jr> k
248 2015-07-11 22:11:16 <phantomcircuit> Luke-Jr, client sends SYN, server sends SYN/ACK, both have randomized the initial sequence number, an attacker would have to guess the random number
249 2015-07-11 22:13:42 <Luke-Jr> anything I should change on this? https://www.reddit.com/r/Bitcoin/comments/3cydqc/bitcoin_core_ljr_0110ljr20150711_available_for/
250 2015-07-11 22:16:34 <michagogo> Luke-Jr: technically 0.11.0 isn't released yet
251 2015-07-11 22:17:08 <michagogo> wumpus hasn't uploaded the bins, posted to the ML, and merged the Bitcoin.org PR yet
252 2015-07-11 22:17:42 <Luke-Jr> oh, why not?
253 2015-07-11 22:18:03 <michagogo> Idk
254 2015-07-11 22:18:09 <michagogo> Probably just hasn't gotten around to it
255 2015-07-11 22:18:23 <michagogo> Also, s/famous/infamous/
256 2015-07-11 22:22:34 <michagogo> Luke-Jr: there is -- I don't really think it needs ACKs
257 2015-07-11 22:22:44 <Luke-Jr> hm, Travis fails on it?
258 2015-07-11 22:22:53 <michagogo> It just needs the binaries uploaded, Travis rerun, and a merge
259 2015-07-11 22:23:00 <michagogo> Yeah, Travis makes sure the bins exist
260 2015-07-11 22:23:09 <Luke-Jr> ah, neat
261 2015-07-11 22:23:09 <michagogo> And they don't.
262 2015-07-11 22:23:44 <Luke-Jr> I have the bins if anyone can upload them
263 2015-07-11 22:24:02 <michagogo> Luke-Jr: needs his sig on SHA256SUMS
264 2015-07-11 22:24:15 <Luke-Jr> hm, I guess that would be ideal, yes
265 2015-07-11 22:24:29 <michagogo> Anyway, he's the release manager
266 2015-07-11 22:24:43 <michagogo> Probably shouldn't bypass that
267 2015-07-11 22:24:52 <Luke-Jr> oh well
268 2015-07-11 22:25:16 <michagogo> Anyway, 1:25 here, and I need to wake up in 4.5 hours
269 2015-07-11 22:25:18 <michagogo> Goodnight
270 2015-07-11 23:07:26 <midnightmagic> isis: Yes, or I can just run it all inside a nestable container with no configured network access except tor, or I can just go in and modify the URLs, or as wumpus said I guess I can override with a gitian URL directory pair, and/or edit the url params in the gitian descriptor, and/or ensure apt-cacher-ng is correctly proxied etc.