--- Day changed Sun Nov 29 2015
00:12 -!- challisto [~challisto@unaffiliated/challisto] has quit [Ping timeout: 264 seconds]
00:21 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
00:25 -!- challisto [~challisto@unaffiliated/challisto] has joined #bitcoin-core-dev
00:57 < phantomcircuit> gmaxwell, what do you think about removing RelayTransaction entirely and simply sending the top n MB of the mempool every m seconds?
00:58 < gmaxwell> phantomcircuit: I want to try a protocol which does an efficient set reconcillation of the top N mb of mempool. Which is like the pro version of what you're thinking.
00:58 < gmaxwell> Not the actual data, but set reconcile the TXids and then getdata the bodies you need.
00:58 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-wrppsqjrgxsfirud] has joined #bitcoin-core-dev
00:59 < phantomcircuit> gmaxwell, yes long term goal for sure
00:59 < phantomcircuit> but i can do this version like
00:59 < phantomcircuit> today
01:02 < phantomcircuit> gmaxwell, can you rename setInventoryKnown to filterInventoryKnown
01:02 < phantomcircuit> there's a bunch of those now that are a bit confusing because of not changing the name
01:18 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
01:29 < phantomcircuit> gmaxwell, im pretty sure there's a bug in 7100
01:29 < phantomcircuit> it looks like you can get a false positive inv for blocks
01:31 < gmaxwell> phantomcircuit: where?
01:33 < phantomcircuit> gmaxwell, "getblocks" calls pfrom->PushInventory which uses setInventoryKnown to decide whether to actually do that
01:33 < phantomcircuit> so a false positive could prevent a block inv as well as tx inv
01:33 < phantomcircuit> i dont much care about tx inv's getting droped but it would be bad for block inv's to be also
01:33 < gmaxwell> agreed.
01:34 < phantomcircuit> so im thinking there needs to be a setInventoryKnownBlocks and filterInventoryKnownTransactions
01:39 < sipa> with 6494 we can just drop the known blocks
01:39 < sipa> as we keep track much more efficiently what peers know
01:44 < phantomcircuit> sipa, yes i agree that's a better solution
01:44 < phantomcircuit> except it's optional so we would still need the setInventoryKnownBlocks
01:44 < phantomcircuit> (or maybe we simply always send block invs ?)
01:45 < sipa> yes, we should always send them
01:47 < sipa> i'll rebase #6494; it's overdue for merging
01:57 < phantomcircuit> gmaxwell, https://github.com/gmaxwell/bitcoin/pull/2
01:57 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection]
01:59 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
02:03 < gmaxwell> woot, managed to apply that without loading the webpage.
02:05 < sipa> you have now passed the entry exam for the school for git wizardry and magic
02:06 < gmaxwell> well the git part was never a problem, just the github part. :P
02:07 < phantomcircuit> just gotta know the special pulls refspec
02:11 < phantomcircuit> sipa, in 7113 you calculate the optimal number of hash functions and then restrict it to 1-50
02:11 < phantomcircuit> why?
02:14 < phantomcircuit> an fp rate of 1/10^15 would get you nHashFuncs ~= 50
02:14 < phantomcircuit> i dont see this being an issue
02:18 < sipa> eh, i guess i wrote that part before realizing that the number of hash finctions only dependee on the fprate :)
02:18 < sipa> functions, depended
02:31 < phantomcircuit> anybody have an opinion of changing gbt to default not mine a transaction until it's been in the mempool for more than a few seconds
02:31 < sipa> phantomcircuit: do that on top of morcos' rewrite then :)
02:32 < phantomcircuit> sipa, it's a trivial 1 line change so i was mostly just wondering about the concept
02:32 < sipa> ok
02:32 < phantomcircuit> it seems like a good idea to me but i just thought of it soo
02:33 < sipa> among miners who are not in a position to exploit high hashrate or fast relay to a majority, that should improve their relay
02:35 < gmaxwell> phantomcircuit: I think it's a good idea. I thought of it before but figured it would screw up the recent improvements. :(
02:35 < sipa> should be trivial now that we remember time-in-mempool
02:36 < gmaxwell> hm. actually yea, you'd just skip them, so it doesn't change the sort.
02:36 < sipa> indeed
02:36 < phantomcircuit> sipa, it's been a trivial 1 loc patch for about a year now
02:36 < sipa> orly?
02:37 < phantomcircuit> actually more than that
02:37 < phantomcircuit> Date:   Mon Nov 11 17:35:14 2013 +1000
02:37 < sipa> ha, wow
02:37 < phantomcircuit> on a related note
02:37 < phantomcircuit> we want to maximally prime the sigcache for receiving a block
02:38 < phantomcircuit> while also limiting the mempool
02:38 < phantomcircuit> these are kind of at odds at the moment
02:38 < gmaxwell> I tried to have sipa verify rejects and it polluted the crap out of his cache.
02:38 < phantomcircuit> i've got a few ideas of how to deal with this but they are admittedly mostly insane
02:38 < gmaxwell> it actually makes sense to verify rejects for several reasons.
02:38 < gmaxwell> but I think we have to improve cache management first.
02:38 < phantomcircuit> gmaxwell, well for a miner you can just run with a huge sigcache
02:39 < phantomcircuit> i've got mine set to 4GB...
02:39 < gmaxwell> Sipa found it was polluting it even with a stupidly big one. (but not that stupidly big)
02:39 < phantomcircuit> yeah the definition of stupidly big varies here :)
02:39 < gmaxwell> phantomcircuit: we'd like to uh.. not centeralize mining "you can mine but if you want a low orphan rate you'll have to dedicate 16GB ram to it.. not great. :P
02:40 < sipa> hey let's use a rolling bloom filter for tue sigcache!!!
02:40 < sipa> *ducks*
02:40 < gmaxwell> but I think ultimately thats the best thing to do, we could try to estimate "reject but still likely to get mined soon based on recent history" but I'd rather spend the complexity on making the cache smarter.
02:41 < phantomcircuit> the cache doesn't evict when a block is found does it?
02:41 < phantomcircuit> that would be an easy win
02:41 < sipa> it does
02:41 < gmaxwell> e.g. attach feerate and "tip change counter" to entries in the cache, and evict using them.
02:41 < phantomcircuit> oh
02:41 < phantomcircuit> nvm
02:41 < phantomcircuit> :|
02:41 < sipa> phantomcircuit: well, it evicts after use in a block
02:41 < gmaxwell> e.g. so on full it evits the lowest feerate that went into the cache the most blocks ago.
02:41 < sipa> but not after use in mempool
02:42 < phantomcircuit> so there is also the issue that processing transactions into the mempool acquires cs_main
02:42 < phantomcircuit> which is bad for latency of gbt calls
02:42 < gmaxwell> (by lowest I don't mean a sort, I mean a N random draw...)
02:42 < phantomcircuit> soooo rpc "addsigcachentries"
02:42  * phantomcircuit runs away
02:44 < gmaxwell> die
02:45 < sipa> rpc "pollutecache"
02:47 < gmaxwell> should just hash random items in memory and add them, some might be signatures.
02:47 < phantomcircuit> :)
02:47 < phantomcircuit> <phantomcircuit> i've got a few ideas of how to deal with this but they are admittedly mostly insane
02:47 < phantomcircuit> i wasn't lying
02:48 < gmaxwell> phantomcircuit: the obvious thing to do is to just have a EWMA minimum feerate for blocks, and any transaction over that, you verify even if its rejected.
02:48 < sipa> phantomcircuit: when you say insane, i should probably start worrying
02:49 < gmaxwell> (or over 0.95 * that)
02:49 < gmaxwell> sipa: dude, not like he's suggesting turning the G/2 nonce into a cryptosystem.
02:49 < tulip> would having two isolated sigcache (rejects, accepts) do roughly the same job? 
02:50 < gmaxwell> tulip: probably no, because the rejects would get polluted and then not be useful (why have it)
02:50 < tulip> people can perform an eviction attack against the rejects cache of course, but that doesn't completely destroy your validation time. 
02:50 < sipa> we don't have a negative cache now
02:51 < tulip> gmaxwell: suppose.
02:53 < sipa> gmaxwell: European Momputer Manufacturers Organization minimum feerate (sorry, google was slow in telling me what ECMA stood for)
02:54 < sipa> Womputer, of course
02:54 < gmaxwell> exponentially weighed moving average.
02:59 < sipa> ah, of course
03:00 < phantomcircuit> gmaxwell, EWMA ?
03:01 < sipa> phantomcircuit: European Momputer Manufacturers Organization.
03:03 < phantomcircuit> oh
03:03 < phantomcircuit> lol derp
03:03 < phantomcircuit> i should have continued reading before asking :)
03:10 < GitHub47> [bitcoin] sipa opened pull request #7129: Direct headers announcement (rebase of #6494) (master...direct-headers-announcement) https://github.com/bitcoin/bitcoin/pull/7129
03:11 -!- MarcoFalke [05c7b6cb@gateway/web/cgi-irc/kiwiirc.com/ip.5.199.182.203] has joined #bitcoin-core-dev
03:14 < gmaxwell> "that isn't merged yet"
03:15 < gmaxwell> "?"
03:16 < sipa> gmaxwell: i'll merge upon happy travis (though maybe someone should proofread my docs)
03:18 < gmaxwell> hm. so I wonder if the sigcache rejects stuff will have less pollution problems once limited mempool is more common?
03:19 < sipa> perhaps yes
03:19 < tulip> sipa: the docs read fine. 
03:21 < phantomcircuit> gmaxwell, probably
03:21 < phantomcircuit> i actually like tulip's suggestion of having two sigcaches
03:21 < phantomcircuit> it handles the "i have lots of memory and dont care" case pretty well
03:27 < gmaxwell> why not have a seperate sigcache for each band of feerate? :P and if the highest feerate cache is full it evits to a lower feerate cache.
03:28 < gmaxwell> oh you could also put a neural network in it, and it could do unsupervised classification to decide which transactions will get confirmed... and ... :P
03:29 < sipa> and then skynet
03:29 < sipa> and a genisys block
03:31 < phantomcircuit> gmaxwell, hr
03:31 < phantomcircuit> har har
03:32 < phantomcircuit> but in all seriousness it's potentially a large win for miners and just annoying for everybody else
03:32 < gmaxwell> oh, and if your cache gets too big you can sign chunks of it and ship it off to peers, and they can send it back if you need it later...
03:32 < gmaxwell> phantomcircuit: not the kind of wins we should be hunting, because it presumes a more centeralized world of mining where running a mining node takes a lot of resources.
03:33 < gmaxwell> Better to spend effort on optimizations that don't need that.
03:35 < phantomcircuit> gmaxwell, which reminds me, what kind of work would you want to see before revising the advise on mining with a pruned node?
03:35 < gmaxwell> I think it's fine already.
03:35 < gmaxwell> "You mean you don't mine exclusively on pruned nodes?"  ... really the worse problem is that you're hosed in index corruption... 
03:37 < phantomcircuit> gmaxwell, miners are hosed if their index is corrupt even without pruning
03:37 < phantomcircuit> hmm i seem to remember asking someone and getting a "wat dont do dat" response recently
03:37 < gmaxwell> it just means a three hour outage vs ... more.
03:37 < gmaxwell> I don't think you got that from me.
03:37 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
03:38 < sipa> you can always make a backup of the block chain data
03:38 < gmaxwell> like... half the reason I care about pruning is to try to rescue p2pool.
03:38 < phantomcircuit> gmaxwell, yes but it might mean running 5 nodes instead of 1
03:38 < sipa> and use that to recover a mining node
03:39 < gmaxwell> the main risk from pruning + mining is that you can't reorg past some depth, which means consensus fault; but we won't let you prune shallower than 288 blocks back to make that not much of a pratical concern.
03:39 < gmaxwell> (or at least if there is a 288 block reorg, manual intervention is.. least of the worries)
03:40 < gmaxwell> though we should make sure that that it cleanly fails (And importantly stops mining) if it tries a reorg beyond pruning.
03:42 < gmaxwell> phantomcircuit: if you're looking for mining related improvments; bringing back the old lukejr patch to forward unverified blocks would be an obvious candidate.
03:44 < gmaxwell> E.g. a new proto messages activated like sendheaders where you can say "here is a block, I haven't verified it"; you're allowed to relay it to others (as non-validated block) without validatiting long as the hash and headers checkout, and so long as it extends the current tip.
03:44 < gmaxwell> when luke did it before, it didn't speed anything up, but that was presumably because of all the dumb sleeps in networking.
03:45 < gmaxwell> I think this would reduce your mining complex by one node, since those relays wouldn't need to lock the chainstate, and so they wouldn't compete with create new block.
03:46 < sipa> checking whether it extends the current tip would need a lock
03:46 < phantomcircuit> gmaxwell, what happens generally if you try a reorg past the pruning depth?
03:46 < phantomcircuit> it should probably pull those blocks from peers
03:46 < gmaxwell> phantomcircuit: it can't. :( :(
03:46 < gmaxwell> undo data is gone too.
03:46 < sipa> though i guess you could have a pindexTipCopy which has an R/W lock, and is updated by the normal sync, but can be read (and used for verification) by other things
03:46 < gmaxwell> someday we could make undo data normative and commit to it, perhaps and then you could pull it.
03:47 < sipa> gmaxwell: i think the biggest bottleneck is the fact that message processing is single threaded
03:47 < tulip> phantomcircuit: 288 blocks is the minimum, if you reorg that far all of your peers have pinged out as well, it gets super messy and everything is likely on fire anyway. 
03:47 < gmaxwell> sipa: doesn't happen that all our messaging hashes the data...
03:47 < sipa> gmaxwell: parse error
03:48 < gmaxwell> I'm just saying that message handling is computationally expensive.
03:48 < sipa> gmaxwell: so?
03:48 < phantomcircuit> gmaxwell, iirc the undo data is much smaller than the blocks
03:48 < sipa> phantomcircuit: a factor of 9
03:48 < phantomcircuit> ok so probably we should keep it going back 9x deeper than we do blocks
03:48 < gmaxwell> phantomcircuit: yes, and we could prune it to different depths, but keeping it all removes a lot of the pruning gains.
03:49 < sipa> gmaxwell: the fact that we're processing a new incoming block for half a second is no reason why we couldn't respond to a ping from another peer
03:50 < gmaxwell> On earlier; though I guess if we introduced a new p2p message for block relay, it should do RNC like compression.
03:50 < phantomcircuit> gmaxwell, for the average pool i suspect relaying before validating anything but the header would be a win even without the new p2p message to prevent getting banned
03:50 < gmaxwell> ... and bring MRU sets back to track what transactions we've sent a peer? :P
03:51 < gmaxwell> phantomcircuit: it's really important to not hand unvalidated blocks to spv clients.
03:53 < tulip> how do you prevent unvalidated blocks from becoming a DoS vector? 25BTC is expensive, but if I can make a block which takes you 2 minutes to validate it when you see it that could be a problem. 
03:54 < tulip> (two minutes of grinding SHA256, then you find you have to reject it) 
03:54 < phantomcircuit> gmaxwell, iirc the message hashing is done in the networking thread so it's at least partially threaded
03:55 < sipa> phantomcircuit: no
03:55 < sipa> only the checksum
03:55 < sipa> i think?
03:55 < sipa> yes
03:55 < phantomcircuit> i thought that's what he was talking about
03:56 < sipa> not the txid's, for example
03:56 < sipa> or sighashes which are even more work
03:56 < tulip> me? I was talking about sighash hashing. 
03:57 < phantomcircuit> tulip, no i was talking about what gmaxwell said
03:57 < tulip> right. 
03:58 < sipa> message handling is of course expensive; it's where block validation (and a part of signature validation even) happens
03:58 < sipa> doesn't mean it needs to be done single threadedly
04:05 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
04:06 < GitHub182> [bitcoin] sipa pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/c894fbbb1dc0...5d5ef3a4cf8e
04:06 < GitHub182> bitcoin/master 50262d8 Suhas Daftuar: Allow block announcements with headers...
04:06 < GitHub182> bitcoin/master 49fb8e8 Pieter Wuille: Documentation updates for BIP 130
04:06 < GitHub182> bitcoin/master 5d5ef3a Pieter Wuille: Merge pull request #7129...
04:06 < GitHub38> [bitcoin] sipa closed pull request #7129: Direct headers announcement (rebase of #6494) (master...direct-headers-announcement) https://github.com/bitcoin/bitcoin/pull/7129
04:07 < GitHub105> [bitcoin] sipa closed pull request #6494: Allow block announcements with headers (master...direct-headers-announcement) https://github.com/bitcoin/bitcoin/pull/6494
05:11 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection]
05:14 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
05:14 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection]
05:17 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
05:19 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection]
05:31 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
06:08 -!- morcos_ [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 240 seconds]
06:08 -!- sdaftuar_ [~sdaftuar@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 260 seconds]
06:09 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
06:09 -!- sdaftuar [~sdaftuar@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
06:29 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev
06:38 -!- tulip [~tulip@unaffiliated/tulip] has quit []
06:42 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
07:35 -!- MarcoFalke [05c7b6cb@gateway/web/cgi-irc/kiwiirc.com/ip.5.199.182.203] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
07:36 -!- guest234234 [~guest2342@223.207.206.21] has quit [Ping timeout: 260 seconds]
08:15 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev
08:18 -!- zookolaptop [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-core-dev
08:19 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 246 seconds]
08:27 -!- dermoth [~thomas@dsl-66-36-138-7.mtl.aei.ca] has quit [Ping timeout: 260 seconds]
08:34 -!- dermoth [~thomas@dsl-66-36-138-7.mtl.aei.ca] has joined #bitcoin-core-dev
08:34 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-wrppsqjrgxsfirud] has quit [Quit: Connection closed for inactivity]
08:37 -!- JackH [~Jack@host-80-43-142-236.as13285.net] has joined #bitcoin-core-dev
08:55 -!- pkthebud [uid128839@gateway/web/irccloud.com/x-vrhjkgtyphtdsadf] has quit [Quit: Connection closed for inactivity]
08:55 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
08:55 -!- instagibbs [~greg@pool-108-31-210-40.washdc.fios.verizon.net] has quit [Ping timeout: 260 seconds]
08:57 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds]
08:59 -!- zookolaptop [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 246 seconds]
09:05 -!- PaulCape_ [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
09:05 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Read error: Connection reset by peer]
09:06 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev
09:07 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Ping timeout: 240 seconds]
09:08 -!- instagibbs [~greg@pool-108-31-210-40.washdc.fios.verizon.net] has joined #bitcoin-core-dev
09:40 < phantomcircuit> morcos, when a block is invalidated are we updating CTxMempoolEntry::hadNoDependencies properly?
09:46 -!- ParadoxSpiral_ [~ParadoxSp@p508B94C6.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
09:49 -!- ParadoxSpiral [~ParadoxSp@p508B8EBD.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds]
09:50 -!- zookolaptop [~user@65-128-80-154.hlrn.qwest.net] has joined #bitcoin-core-dev
09:53 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-hrbmoouehjexstdk] has joined #bitcoin-core-dev
10:15 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
10:21 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer]
10:24 -!- zookolaptop [~user@65-128-80-154.hlrn.qwest.net] has quit [Ping timeout: 264 seconds]
10:31 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
10:43 -!- arubi [~ese168@unaffiliated/arubi] has quit [Quit: Leaving]
10:43 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev
10:48 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev
11:04 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
11:09 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
11:33 -!- zookolaptop [~user@65-128-80-154.hlrn.qwest.net] has joined #bitcoin-core-dev
11:51 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
12:24 -!- raedah [~raedah@172.56.39.224] has joined #bitcoin-core-dev
12:32 -!- cocoBTC [~cocoBTC__@c-233a71d5.136-1-64736c10.cust.bredbandsbolaget.se] has joined #bitcoin-core-dev
12:32 -!- zookolaptop [~user@65-128-80-154.hlrn.qwest.net] has quit [Ping timeout: 272 seconds]
12:36 -!- instagibbs [~greg@pool-108-31-210-40.washdc.fios.verizon.net] has quit [Ping timeout: 276 seconds]
12:37 -!- instagibbs [~greg@pool-108-31-210-40.washdc.fios.verizon.net] has joined #bitcoin-core-dev
12:38 -!- helo [~helo@unaffiliated/helo] has quit [Ping timeout: 276 seconds]
12:39 -!- helo [~helo@unaffiliated/helo] has joined #bitcoin-core-dev
12:40 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
12:42 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Ping timeout: 264 seconds]
12:43 -!- raedah [~raedah@172.56.39.224] has quit [Ping timeout: 264 seconds]
12:43 -!- PaulCape_ [~PaulCapes@204.28.124.82] has quit [Ping timeout: 264 seconds]
13:11 -!- Netsplit *.net <-> *.split quits: ParadoxSpiral_, teward, pigeons, d_t, Taek, PRab, crescend1, Apocalyptic, helo
13:11 -!- Netsplit over, joins: helo
13:12 -!- crescendo [~mozart@unaffiliated/crescendo] has joined #bitcoin-core-dev
13:12 -!- PRab [~chatzilla@68.34.102.231] has joined #bitcoin-core-dev
13:17 -!- d_t [~textual@50.136.139.144] has joined #bitcoin-core-dev
13:20 -!- Netsplit over, joins: teward
13:24 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-hrbmoouehjexstdk] has quit [Ping timeout: 264 seconds]
13:25 -!- Taek [~quassel@ks36119.kimsufi.com] has joined #bitcoin-core-dev
13:33 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-haknuatblmndsrbe] has joined #bitcoin-core-dev
13:34 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
13:35 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Ping timeout: 260 seconds]
13:37 -!- Netsplit over, joins: Apocalyptic
13:37 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-core-dev
13:40 -!- Netsplit over, joins: pigeons
13:40 -!- pigeons is now known as Guest23613
13:43 -!- luke-jr_ [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
13:43 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
13:46 -!- luke-jr_ [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
13:48 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has quit [Ping timeout: 264 seconds]
13:51 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
13:55 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has joined #bitcoin-core-dev
14:03 -!- Guest23613 is now known as pigeons
--- Log closed Sun Nov 29 14:12:51 2015
--- Log opened Sun Nov 29 14:44:44 2015
14:44 -!- kanzure [~kanzure@bryan.fairlystable.org] has joined #bitcoin-core-dev
14:44 -!- Irssi: #bitcoin-core-dev: Total of 79 nicks [0 ops, 0 halfops, 0 voices, 79 normal]
14:45 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
14:45 -!- isis [~isis@abulafia.patternsinthevoid.net] has joined #bitcoin-core-dev
14:46 < phantomcircuit> morcos, optimal is probably very hard
14:46 -!- Ylbam [uid99779@gateway/web/irccloud.com/session] has joined #bitcoin-core-dev
14:46 -!- jcorgan [~jcorgan@ec2-54-67-38-167.us-west-1.compute.amazonaws.com] has joined #bitcoin-core-dev
14:46 -!- jcorgan [~jcorgan@ec2-54-67-38-167.us-west-1.compute.amazonaws.com] has quit [Changing host]
14:46 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev
14:47 < phantomcircuit> morcos, knapsack problem with at least two optimization variables :|
14:47 < sipa> s/optimal/an approximation of optimal with reasonable conputational limits/
14:51 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has joined #bitcoin-core-dev
14:53 -!- Irssi: Join to #bitcoin-core-dev was synced in 519 secs
14:53 -!- Anduck_ [~anduck@aom.fi] has joined #bitcoin-core-dev
14:53 -!- Anduck_ [~anduck@aom.fi] has quit [Client Quit]
14:54 -!- Guest76338 [~anduck@aom.fi] has joined #bitcoin-core-dev
14:54 -!- Guest76338 [~anduck@aom.fi] has quit [Client Quit]
14:55 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev
14:55 -!- Anduck__ [~anduck@aom.fi] has joined #bitcoin-core-dev
14:56 -!- gmaxwell [greg@mf4-xiph.osuosl.org] has joined #bitcoin-core-dev
14:56 -!- Anduck__ [~anduck@aom.fi] has quit [Client Quit]
14:57 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has quit [Ping timeout: 264 seconds]
14:57 -!- gmaxwell is now known as Guest19298
14:57 -!- Anduck__ [~anduck@unaffiliated/anduck] has joined #bitcoin-core-dev
14:59 -!- Anduck [~anduck@unaffiliated/anduck] has quit [Disconnected by services]
14:59 -!- Anduck__ is now known as Anduck
15:04 -!- Guest19298 [greg@mf4-xiph.osuosl.org] has quit [Changing host]
15:04 -!- Guest19298 [greg@wikimedia/KatWalsh/x-0001] has joined #bitcoin-core-dev
15:05 -!- Guest19298 is now known as gmaxwell
15:08 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
15:11 -!- BashCo [~BashCo@unaffiliated/bashco] has quit []
15:12 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has joined #bitcoin-core-dev
15:18 -!- guest234234 [~guest2342@223.207.206.176] has joined #bitcoin-core-dev
15:24 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
15:25 -!- berndj [~berndj@197.242.93.82] has joined #bitcoin-core-dev
15:32 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has quit [Ping timeout: 264 seconds]
15:32 -!- cocoBTC [~cocoBTC__@c-233a71d5.136-1-64736c10.cust.bredbandsbolaget.se] has quit [Quit: Leaving]
15:34 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has joined #bitcoin-core-dev
15:57 -!- Ylbam [uid99779@gateway/web/irccloud.com/session] has quit [Ping timeout: 264 seconds]
15:59 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
16:04 -!- Ylbam [uid99779@gateway/web/irccloud.com/session] has joined #bitcoin-core-dev
16:18 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has quit [Ping timeout: 264 seconds]
16:22 < andytoshi> does fundmany support a way to restrict the input set to only sufficiently confirmed outputs?
16:22 < andytoshi> if i submit a PR to add this functionality (haven't scoped this out, idk if it's easy) would it be supported?
16:24 < andytoshi> err, fundrawtransaction
16:26 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has joined #bitcoin-core-dev
16:35 < gmaxwell> andytoshi: it uses the normal selection logic:  only mature inputs unless they're from yourself.
16:36 < sipa> you can globally disable -spendzeroconfchange=0 or so
16:36 < gmaxwell> then only >=1 conf, unless it still can't be successful, then unconfirmed, unless -spendzeroconfchange=0
16:40 < sipa> it first tries only 6 confirms; if that doesn't work it tries 1 confirm; if that does work and spednzeroconfchange is set it tries 0 confirmed change and 1 confirms for all the rest
16:43 -!- Apocalyptic [~Apocalypt@unaffiliated/apocalyptic] has quit [Ping timeout: 245 seconds]
16:43 -!- Dyanisus [~Dyanisus@unaffiliated/dyanisus] has quit [Ping timeout: 260 seconds]
16:46 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has quit [Ping timeout: 245 seconds]
16:46 < andytoshi> sipa: gmaxwell: elements alpha uses this RPC to fund withdrawwatch transactions, which basically means the functionary policy is set by CAre
16:46 < andytoshi> Core
16:47 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has quit [Ping timeout: 264 seconds]
16:47 < andytoshi> well, in this specific are
16:47 < andytoshi> area
16:47 < sipa> andytoshi: good thing bitcoin core uses a reasonable policy :)
16:47 < andytoshi> hehe : )
16:48 -!- Apocalyptic [~Apocalypt@unaffiliated/apocalyptic] has joined #bitcoin-core-dev
17:09 -!- harding_ is now known as harding
17:09 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has joined #bitcoin-core-dev
17:09 -!- tripleslash_u is now known as tripleslash
17:16 -!- Dyanisus [~Dyanisus@unaffiliated/dyanisus] has joined #bitcoin-core-dev
17:21 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has joined #bitcoin-core-dev
17:35 -!- CodeShark_ [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-core-dev
17:42 -!- guest234234 [~guest2342@223.207.206.176] has quit [Read error: Connection reset by peer]
17:43 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has quit [Ping timeout: 264 seconds]
17:49 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has joined #bitcoin-core-dev
17:52 -!- guest234234 [~guest2342@223.207.206.176] has joined #bitcoin-core-dev
17:54 -!- Ylbam [uid99779@gateway/web/irccloud.com/session] has quit [Quit: Connection closed for inactivity]
17:55 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has quit [Ping timeout: 264 seconds]
18:05 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has joined #bitcoin-core-dev
18:15 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has quit [Ping timeout: 264 seconds]
18:23 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has joined #bitcoin-core-dev
18:33 -!- CodeShark_ [CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 245 seconds]
18:37 -!- guest234234 [~guest2342@223.207.206.176] has quit [Ping timeout: 244 seconds]
19:19 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has quit [Ping timeout: 264 seconds]
19:20 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has joined #bitcoin-core-dev
19:25 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has quit [Ping timeout: 264 seconds]
19:35 -!- guest234234 [~guest2342@223.207.206.176] has joined #bitcoin-core-dev
19:40 -!- proem [~sid62269@158.69.194.36] has joined #bitcoin-core-dev
19:45 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has joined #bitcoin-core-dev
19:51 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has quit [Ping timeout: 264 seconds]
19:51 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has quit [Ping timeout: 245 seconds]
19:57 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has joined #bitcoin-core-dev
20:16 -!- CodeShark_ [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-core-dev
20:22 -!- jtimon [~quassel@74.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 242 seconds]
20:39 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has quit [Ping timeout: 264 seconds]
20:48 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has joined #bitcoin-core-dev
21:10 -!- proem [~sid62269@158.69.194.36] has quit [K-Lined]
21:13 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has quit [Ping timeout: 264 seconds]
21:16 -!- d_t [~textual@50.136.139.144] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
21:17 -!- Dyanisus [~Dyanisus@unaffiliated/dyanisus] has quit [Ping timeout: 244 seconds]
21:21 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has joined #bitcoin-core-dev
21:28 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has quit [Ping timeout: 264 seconds]
21:30 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has joined #bitcoin-core-dev
21:40 < dgenr8> s/optimal/incentive-aligned/... relay policy can't be thought of as an optimization problem, too many independent actors involved.
21:40 < dgenr8> Child-alone-pays-for-all-ancestors is simple and incentive-aligned. It should work for CNB too, though it may miss edge case opportunities.
21:43 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 240 seconds]
21:45 -!- Apocalyptic [~Apocalypt@unaffiliated/apocalyptic] has quit [Ping timeout: 245 seconds]
21:51 -!- decalobate [~Taylor@2001:41d0:a:4f83::] has joined #bitcoin-core-dev
21:54 -!- decalobate [~Taylor@2001:41d0:a:4f83::] has quit [Excess Flood]
22:13 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has quit [Ping timeout: 264 seconds]
22:18 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has joined #bitcoin-core-dev
22:23 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Ping timeout: 244 seconds]
22:37 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has quit [Ping timeout: 264 seconds]
22:47 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has joined #bitcoin-core-dev
22:55 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has quit [Ping timeout: 264 seconds]
22:55 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has joined #bitcoin-core-dev
22:56 -!- Ylbam [uid99779@gateway/web/irccloud.com/session] has joined #bitcoin-core-dev
23:08 -!- Ylbam [uid99779@gateway/web/irccloud.com/session] has quit [Read error: Connection reset by peer]
23:09 -!- Ylbam [uid99779@gateway/web/irccloud.com/session] has joined #bitcoin-core-dev
23:09 -!- guest234234 [~guest2342@223.207.206.176] has quit [Ping timeout: 244 seconds]
23:14 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has quit [Ping timeout: 264 seconds]
23:18 -!- guest234234 [~guest2342@223.207.206.176] has joined #bitcoin-core-dev
23:23 -!- guest234234 [~guest2342@223.207.206.176] has quit [Ping timeout: 244 seconds]
23:29 -!- guest234234 [~guest2342@223.207.206.176] has joined #bitcoin-core-dev
23:34 -!- guest234234 [~guest2342@223.207.206.176] has quit [Ping timeout: 244 seconds]
23:40 -!- Dyanisus [~Dyanisus@unaffiliated/dyanisus] has joined #bitcoin-core-dev
23:55 < gmaxwell> Just so people aren't caught surprised, the addtion of Opt-in RBF to Bitcoin Core has inspired a seemingly organized misinformation campaign that has been spiraling all over the place. I've been maintaining a FAQ on reddit: https://www.reddit.com/r/Bitcoin/comments/3urm8o/optin_rbf_is_misunderstood_ask_questions_about_it/