--- Day changed Sat Dec 12 2015
00:47 -!- tulip [~tulip@unaffiliated/tulip] has quit [Quit: tulip]
01:05 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-evjuxiloubrszvsz] has joined #bitcoin-core-dev
01:27 -!- jtimon [~quassel@74.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
01:38 -!- jtimon [~quassel@74.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 272 seconds]
01:52 -!- Tera2342 [~Tera2342@171.5.144.9] has joined #bitcoin-core-dev
01:55 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Remote host closed the connection]
01:56 -!- ParadoxSpiral [~ParadoxSp@p508B8FD4.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
01:58 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
--- Log closed Sat Dec 12 02:09:17 2015
--- Log opened Sat Dec 12 02:09:45 2015
02:09 -!- kanzure_ [~kanzure@bryan.fairlystable.org] has joined #bitcoin-core-dev
02:09 -!- Irssi: #bitcoin-core-dev: Total of 89 nicks [0 ops, 0 halfops, 0 voices, 89 normal]
02:10 -!- xiangfu_ [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev
02:10 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has quit [Ping timeout: 240 seconds]
02:10 -!- ParadoxSpiral [~ParadoxSp@p508B8FD4.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
02:10 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has quit [Ping timeout: 240 seconds]
02:10 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Ping timeout: 240 seconds]
02:10 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Ping timeout: 240 seconds]
02:11 -!- kanzure [~kanzure@bryan.fairlystable.org] has quit [Ping timeout: 240 seconds]
02:11 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Ping timeout: 240 seconds]
02:11 -!- harding [~harding@mail.dtrt.org] has quit [Remote host closed the connection]
02:11 -!- harding [~harding@mail.dtrt.org] has joined #bitcoin-core-dev
02:11 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
02:11 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
02:11 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
02:12 -!- ParadoxSpiral [~ParadoxSp@p508B8FD4.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
02:12 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #bitcoin-core-dev
02:14 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.]
02:14 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev
02:16 -!- harding_ [~harding@mail.dtrt.org] has joined #bitcoin-core-dev
02:17 -!- davec_ [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
02:17 -!- Irssi: Join to #bitcoin-core-dev was synced in 516 secs
02:18 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has quit [Ping timeout: 240 seconds]
02:18 -!- harding [~harding@mail.dtrt.org] has quit [Ping timeout: 240 seconds]
02:18 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
02:18 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Remote host closed the connection]
02:19 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Remote host closed the connection]
02:20 -!- Thireus [~Thireus@37.235.49.227] has joined #bitcoin-core-dev
02:53 -!- blkdb [~blkdb@2a01:4f8:212:1ea2::2] has quit [Remote host closed the connection]
02:53 -!- blkdb [~blkdb@2a01:4f8:212:1ea2::2] has joined #bitcoin-core-dev
03:41 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
04:28 -!- tulip [~tulip@unaffiliated/tulip] has joined #bitcoin-core-dev
05:37 -!- ParadoxSpiral [~ParadoxSp@p508B8FD4.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds]
06:23 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-core-dev
06:23 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has quit [Changing host]
06:23 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
06:53 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
07:03 -!- Tera2342 [~Tera2342@171.5.144.9] has quit [Ping timeout: 256 seconds]
07:07 -!- fkhan [weechat@gateway/vpn/mullvad/x-lmiuaohbnwqaxiet] has quit [Ping timeout: 256 seconds]
07:14 -!- dermoth [~thomas@dsl-216-221-38-191.mtl.aei.ca] has quit [Ping timeout: 256 seconds]
07:20 -!- fkhan [weechat@gateway/vpn/mullvad/x-fjinjzkztxjhdlob] has joined #bitcoin-core-dev
07:39 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 264 seconds]
07:45 -!- You're now known as kanure
07:45 -!- You're now known as kanzure
07:53 -!- ParadoxSpiral [~ParadoxSp@p508B9418.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
08:15 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
08:30 -!- andytoshi [~andytoshi@wpsoftware.net] has quit [Changing host]
08:30 -!- andytoshi [~andytoshi@unaffiliated/andytoshi] has joined #bitcoin-core-dev
08:36 -!- bawong [~rich@c-50-184-106-81.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
09:14 -!- corb [~Jack@host-80-43-140-204.as13285.net] has joined #bitcoin-core-dev
09:32 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 240 seconds]
09:35 -!- s1w- [~s1w@128.199.100.16] has joined #bitcoin-core-dev
09:36 -!- btcdrak_ [uid115429@gateway/web/irccloud.com/x-sgzicjiphxigkbmd] has joined #bitcoin-core-dev
09:38 -!- tulp [~tulip@unaffiliated/tulip] has joined #bitcoin-core-dev
09:40 -!- Netsplit *.net <-> *.split quits: btcdrak, tulip, s1w
09:40 -!- tulp is now known as tulip
09:41 -!- btcdrak_ is now known as btcdrak
09:54 -!- bawong [~rich@c-50-184-106-81.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]
10:11 < GitHub166> [bitcoin] smenglish opened pull request #7201: Update hmac_sha256.cpp (master...master) https://github.com/bitcoin/bitcoin/pull/7201
10:17 -!- bawong [~rich@c-50-184-106-81.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
10:41 -!- bawong [~rich@c-50-184-106-81.hsd1.ca.comcast.net] has quit [Ping timeout: 250 seconds]
10:45 < devrandom> Luke-Jr, wumpus: I updated the gitian RELEASE_NOTES to note the move to RSA keys
10:45 < devrandom> let me know if anything else is needed
10:52 -!- corb [~Jack@host-80-43-140-204.as13285.net] has quit [Ping timeout: 240 seconds]
10:59 -!- corb [~Jack@host-80-43-140-204.as13285.net] has joined #bitcoin-core-dev
12:09 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 250 seconds]
12:12 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev
12:26 -!- sipa [~pw@2a02:348:86:3011::1] has joined #bitcoin-core-dev
12:32 -!- jtimon [~quassel@74.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
12:38 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
12:54 < Luke-Jr> how do depends/ determine their sourcecode-path?
12:58 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
13:12 -!- bitdevsnyc [bitdevsnyc@gateway/vpn/mullvad/x-nzfwsqynpnpwgcsu] has joined #bitcoin-core-dev
13:20 < Luke-Jr> bleh, depends seems pretty buggy in general
13:21 < Luke-Jr> why is my native stuff going under built/x86_64-pc-linux-gnu/ when my OS is i686-pc-linux-gnu?
13:27 -!- bitdevsn_ [~bitdevsny@cpe-158-222-198-108.nyc.res.rr.com] has joined #bitcoin-core-dev
13:29 -!- bitdevsnyc [bitdevsnyc@gateway/vpn/mullvad/x-nzfwsqynpnpwgcsu] has quit [Ping timeout: 240 seconds]
13:42 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
13:42 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
14:28 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Quit: Arnavion]
14:29 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
14:34 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 240 seconds]
14:35 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer]
14:39 -!- bitdevsn_ [~bitdevsny@cpe-158-222-198-108.nyc.res.rr.com] has quit [Remote host closed the connection]
14:39 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Quit: Arnavion]
14:40 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
14:41 -!- bitdevsnyc [~bitdevsny@cpe-158-222-198-108.nyc.res.rr.com] has joined #bitcoin-core-dev
14:41 -!- bitdevsnyc [~bitdevsny@cpe-158-222-198-108.nyc.res.rr.com] has quit [Remote host closed the connection]
14:42 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev
15:10 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 240 seconds]
15:19 -!- arowser [~quassel@106.120.101.38] has quit [Ping timeout: 250 seconds]
15:19 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev
15:19 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev
16:18 -!- phantomcircuit [phantomcir@2600:3c01::f03c:91ff:fe73:6892] has quit [Read error: Connection reset by peer]
16:21 < gmaxwell> sipa: I think your latest update to 7125 is wrong.
16:21 < sipa> oh?
16:21 < gmaxwell> +    return nNow + (int64_t)(log1p(GetRand(1ULL << 48) * -0.0000000000000035527136788 /* -1/2^48 */) * average_interval_seconds * -1000000.0 + 0.5);
16:22 < gmaxwell> I think thats returning microseconds, not ms. And I think the now units are .. oh nevermind!
16:22 < sipa> getrand returns a result in [0, 1-1/2^48]
16:22 < sipa> ok
16:23 < sipa> it's in the comments even, i think :)
16:23 < sipa> i've tested it by adding a LogPrintf that writes out the new timestamp
16:24 < sipa> the results looks reasonably random around 5s
16:24 < gmaxwell> sipa: yea, in the header. I'd just gone to look to see what the longest number it would return, and got something that was much larger than I expected.
16:24 < gmaxwell> but thats because for some reason I thought it was using ms not microseconds. :)
16:28 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
16:31 -!- phantomcircuit [phantomcir@2600:3c01::f03c:91ff:fe73:6892] has joined #bitcoin-core-dev
16:39 -!- bawong [~rich@c-50-184-106-81.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
16:42 -!- Tera2342 [~Tera2342@171.5.144.9] has joined #bitcoin-core-dev
17:02 -!- bawong [~rich@c-50-184-106-81.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]
17:03 -!- raedah [~raedah@172.56.39.66] has joined #bitcoin-core-dev
17:38 -!- bawong [~rich@c-50-184-106-81.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
17:41 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-evjuxiloubrszvsz] has quit [Quit: Connection closed for inactivity]
18:05 -!- andytoshi [~andytoshi@unaffiliated/andytoshi] has quit [Ping timeout: 250 seconds]
18:17 -!- andytoshi [~andytoshi@wpsoftware.net] has joined #bitcoin-core-dev
18:50 < morcos> gmaxwell: i'm trying to understand what you were talking about yesterday with the tiered fee behavior
18:50 < morcos> are you talking about this is how mempools would behave?  
18:51 < morcos> and the target size is how big you wanted to limit your mempool to?
18:51 < morcos> or are you talking about something to do with block assembly?
18:51 < gmaxwell> The latter-- block assembly.
18:52 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
18:52 < morcos> I'm not quite understanding the purpose
18:52 < morcos> you still suggest to add in a fee sorted manner
18:53 < morcos> but you want to have the min fee which is required start going up as the block gets bigger?
18:53 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
18:53 -!- Tera2342 [~Tera2342@171.5.144.9] has quit [Ping timeout: 250 seconds]
18:54 < gmaxwell> Thats what Bitcoin did in 2012 and before, and I think the actual implementation wasn't a good path. It's weird to have such a huge amount of statefulness regarding when transactions come in.
18:54 < morcos> the idea being that before the block has decent size that from a long term perspective you need to be adding at least some txs or bitcoin is useless, but once it gets of a decent size, then you need to worry more about what the profit maximizing strategy is?
18:55 < morcos> well i just don't understand why the min fee would ever go above what the orphan risk equilibrium rate is though?
18:56 < morcos> i think you have a point that we may not have properly been considering the importance of that.   and it might make sense to for example add a separate configurable parameter which is the min mining fee rate.
18:56 < morcos> but i'm hesitant to jump to the conclusion that we've been that far off.
18:57 < gmaxwell> Consider, right now imagine we get 4 blocks in a row in 5 minutes.  We'd end up with 4 750k (or 1MB blocks) that dig deep into the mempool and mine a bunch of low fee transactions (including maliciously created spam attack crap). The result is that the fee behavior is fairly unpredictable. 
18:57 < morcos> does the orphan rate really depend on block size, or is it validation cose for which block size is a semi decent proxy?
18:57 < gmaxwell> morcos: I don't think most people mining have done the math. At least the amounts involved right now are below the threshold where it probably matters; and doubly so w/ pools where the pool operator is mostly not eating the cost of their decision.
18:58 < morcos> yes, but shouldn't there just be a single cut-off point for where its no longer profitable to add txs..  and who cares if you get down closer to that sometimes when there are quick blocks in succession.  as long as you're not ever going below that?
18:59 < gmaxwell> morcos: yes, there should be.
18:59 < phantomcircuit> morcos, orphan rate is roughly proportional to the size of the transactions weighted by transaction age
19:00 < phantomcircuit> ie newer transactions are likely to take longer to validate and thus increase orphan rate
19:00 < gmaxwell> phantomcircuit: I've not seen data to support that (though it's plausable), I don't know how to factor it in.
19:00 < morcos> seems like even more accurate would be to look at number of differet txs in the prevouts
19:00 < phantomcircuit> gmaxwell, the effect is marginal at the moment because of gbt latency
19:01 < gmaxwell> morcos: relay network is responsable for carrying most blocks between miners and its hitrate probably makes a much bigger difference than UTXO cache hitrate.
19:02 < gmaxwell> phantomcircuit: I think it wouldn't be imprudent to just skip any transaciton you've known about for less than a few seconds while constructing a block, and doing so would probably eliminate the effect you're talking about.
19:02 < morcos> so actual bandwidth is a limiting factor then
19:03 < phantomcircuit> gmaxwell, yes
19:03 < gmaxwell> phantomcircuit: though a more intelligent approach would adjust the minimum fee based on how long you've know about it.. the 100BTC fee transaction you take right away. :)
19:03 < morcos> ha.. maybe, or maybe you don't want your block reward lost in a reorg.  :)
19:04 < gmaxwell> hah, okay 100 is a bit high for that example.
19:04 < morcos> i think spending some time thinking about this is a good idea
19:04 < morcos> maybe we don't find any serious concerns
19:04 < morcos> but with the halvening coming up..  it might make things matter that didn't use to
19:05 < phantomcircuit> gmaxwell, yes but that's slightly harder to calculate :)
19:05 < gmaxwell> morcos: the direction I was more thinking in terms was "control stability"; we have variable fees coming in, variable block times.  And then just a max block size wall. It doesn't make for very stable control of the system.
19:06 < morcos> yeah i guess thats what i'm not following
19:06 < morcos> i think that maybe thats true looking at a very short time frame
19:06 < morcos> but the whole point is the block time variability is what lets you pay less for slower confirmation
19:06 < morcos> or are you thinking with respect to block size limits
19:07 < morcos> like if we were to increase them, maybe we don't either by consensus or default inrease them as much when they are in quick succession
19:07 < morcos> i guess thats hard to do by consensus
19:08 < phantomcircuit> gmaxwell, unfortunately the way to fix that is convoluted and a hard fork
19:08 < gmaxwell> My thoughts really aren't clear on where to go from this; but the observation is that the old fee scheme provided backpressure.
19:08 < phantomcircuit> adjust the max block size based on the timestamp (oh and can/will be manipulated by miners)
19:09 < morcos> i guess the way i imagine the system is we should assume that blocks will always be 100% full
19:09 < gmaxwell> in a way that was more gradual that "is load currently over limit yes/no"? 
19:09 < gmaxwell> morcos: yes, we should. I agree, long run.
19:10 < gmaxwell> but at the region where we don't quite have enough transaction load paying fees which are high enough to discourage abuse or even high enough to be rational to mine, I think there is a stability problem.
19:10 < gmaxwell> Maybe it's just short term and we shouldn't worry about it.
19:11 < gmaxwell> Part of why I brought up that miners now widely mine txn that are almost certantly irrational to mine was basically to make an argument that we probably could do something that lowered incomes slightly but improved stability.
19:12 < gmaxwell> (and, ultimately, some later dynamic blocksize maximum could make that stability promoting behavior also the income maximizing one)
19:12 < morcos> yeah thats the way i'd look at it, the instability is in the super low fee/free tx region which are essentially bonus anyway.  for fee payign txs, they are super stable now.
19:12 < gmaxwell> Okay, I agree with that.
19:12 < morcos> but maybe i'm not understanding stability of what
19:13 < morcos> hmm
19:13 < morcos> yeah so if you're a miner
19:13 < gmaxwell> Basically the system currently encourages you to play block arrival time chicken. Pay massively low fees, get mined fast. hurray!  ... next time, mined slowly "Boo bitcoin is broken!" 
19:13 < phantomcircuit> gmaxwell, what's the formula you were saying governs the maximum feerate a miner should include?
19:14 < morcos> you could sabotage other miners by feeding them and only them a bunch of txs which will make their blocks slower to mine..  but i guess they'd relay those txs themselves
19:15 < morcos> i'm very curious to see if your stratum timings change by much after 0.12
19:15 -!- bawong [~rich@c-50-184-106-81.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]
19:16 < gmaxwell> phantomcircuit: assuming all miners, all transactions are equal.  marginal cost in btc/kb for byte N in a block is ...
19:16 < gmaxwell> 16:03 < gmaxwell> In any case, formula for marginal feerate in order to overcome subsidy loss; there are an infinite numbe
19:16 < gmaxwell> r of tiny miners who all have the same constant and size sensitive delays is (41.6623*e^(((-0.00166649*size)/bytes_per_sec
19:16 < gmaxwell> )-0.00166649*delay_sec))/bytes_per_sec    (this is just the derivative of the orphaning cost for a given size/delay/bandwi
19:16 < gmaxwell> dth assuming 600s blocks)
19:17 < gmaxwell> 16:04 -!- amiller [~socrates1@unaffiliated/socrates1024] has quit [Quit: ZNC - http://znc.sourceforge.net]
19:17 < gmaxwell> 16:07 < gmaxwell> (thats for btc per 1000 bytes, which is usually the unit we use for fees)  
19:17 < gmaxwell> 16:08 < gmaxwell> For 2.491s/90415 bytes/s which were the straum observed measurements; this function is nearly linear in the domain 0-1mb, 0.0004588 to 0.000450 BTC/kb. 
19:17 < gmaxwell> phantomcircuit: it's jut taking the probablity that a block was found before you, given an amount of dealy * 25 btc.
19:17 < gmaxwell> and taking the derivative of it.
19:18 < morcos> when you say block found before you, what does that mean
19:18 < phantomcircuit> and of course if you s/25/0/ it's "build infinite blocks"
19:18 < morcos> that you would have lost the orphan race?
19:18 < morcos> or are you not taking that into account
19:18 < gmaxwell> morcos: they should be; patrick has a stratum server running 0.12 and it's pretty much the fastest stratum server except f2pool mines a block.
19:19 < gmaxwell> morcos: that you would have lost an orphan race.
19:20 < gmaxwell> that figure ignores the fees taken so far; but I thought it was fine to do so consider how small they usually are.
19:20 < phantomcircuit> gmaxwell, it's roughly the same speed when run with the "empty blocks first" patch
19:20 < morcos> 2.5 sec seems like so many
19:20 < phantomcircuit> i mean 0.11.2 is
19:20 < phantomcircuit> forgot words there
19:21 < morcos> if you're somehow aware another block has been found in less than that
19:21 < morcos> oh 
19:21 < morcos> interesting
19:21 < morcos> nvm, i guess invs tell you it was a block, i was thinking you didn't know that
19:22 < phantomcircuit> warmcache rpc + empty blocks results in basically instantly returning a new template
19:22 < morcos> yeah so you get a block inv.  for the next XX ms you should switch your mining hardware to mine an empty block
19:22 < morcos> until you at least have th headers or block to build off of for the next one
19:22 < morcos> that way if you happen to find a block you might beat out the other guy
19:22 < phantomcircuit> morcos, the empty block patch isn't spv/stratum "verification"
19:23 < morcos> yeah i'm suggesting a different kind of empty block
19:23 < phantomcircuit> you actually verify the previous block and then simply short circuit getblocktemplate to return an empty transactions list
19:23 < morcos> you're aware a block has been found, but not even the headers for it yet
19:23 < morcos> you mine empty block on the old tip, so if you happen to find one
19:23 < phantomcircuit> i can think of at least a few reasons that doing that is a bad idea :)
19:23 < morcos> you have a chance of winning the orphan race
19:23 < phantomcircuit> "hey morcor i found a new block!"
19:24 < morcos> yes yea
19:24 < phantomcircuit> repeat every 1 second
19:24 < morcos> but worst case is you give up fees which are small anyway
19:24 < morcos> anyway, in direct headers announcement
19:24 < morcos> you'll have the header so they coudln't do that
19:24 < morcos> and if you don't want to validationless mine
19:25 < morcos> whatever its an over optimization
19:25 < morcos> but 2.5 seconds!
19:25 < morcos> just craz
19:25 < morcos> y
19:25 < phantomcircuit> morcos, huh?
19:25 < gmaxwell> Yea, it's surprisingly high but there are many sources of latency.
19:25 < phantomcircuit> morcos, without fully optimizing im currently 1 second behind f2pool
19:26 < morcos> ok so help me understand that
19:26 < phantomcircuit> im certain i can reduce that more
19:26 < morcos> why?
19:26 < morcos> f2pool is mining on top of a valid PoW header as soon as they have it?
19:26 < phantomcircuit> speed of light beijing to montreal for one
19:27 < morcos> lot less than 1 sec!
19:27 < phantomcircuit> another few hundred ms for TestBlockValidity
19:27 < phantomcircuit> (less with the empty blocks patch)
19:27 < gmaxwell> The switch to empty blocks to optimize the race on the tip may not be so interesting just given how long it takes to retask hardware.
19:27 < morcos> ah, right two validations, you have to validate the new block, and your template
19:27 < gmaxwell> yea, f2pool will mine without validating at all. 
19:28 < phantomcircuit> gmaxwell, afaik there's no good reason for the switching time to be so high
19:28 < morcos> i think whoever was trying to patch to move TBV out of path has a good idea
19:28 < gmaxwell> I agree.
19:28 < phantomcircuit> the only hardware i ever directly wrote drivers for switched in 40ms max
19:28 < morcos> no reason for it to be in path, if it fails you're screwed anyway, might as well find out 30 sec later
19:29 < gmaxwell> that was lightsword.  It does create a little more risk for other users of the network, but I think its acceptable.
19:29 < phantomcircuit> morcos, huh? if TBV fails you're not screwed
19:29 < gmaxwell> (because you might create an invalid block; and it might escape your infrastructure and get handed to a SPV client.. but .. oh well, hardware/software faults can do that)
19:29 < morcos> phantomcircuit: i've been trying to understand how that works in practice
19:30 < phantomcircuit> morcos, any competently written pool software gets block templates from multiple bitcoind nodes
19:30 < morcos> right ok
19:30 < morcos> and they are presumably running different code? (they should!)
19:30 < tulip> most seem to share code to some degree. 
19:30 < phantomcircuit> i'd bet 99% of people are running identical code
19:31 < morcos> and if one fails then it just fails over to using the other one?
19:31 < gmaxwell> he means the different nodes.
19:31 < morcos> right, i mean .11.2 and .12.0
19:31 < tulip> what's a failure?
19:31 < gmaxwell> Eligius has done that in the past, I'm not aware of anyone else doing that. Many large miners replicate their setup and upgrade in chunks but don't have smart failover.
19:31 < phantomcircuit> morcos, i cant answer that definitely but they should be
19:31 < tulip> if two software versions turn out to be consensus incompatible a failover is sort of hard to put into logic. 
19:31 < gmaxwell> Our software reliablity is greater than their planning horizon. :)
19:32 < phantomcircuit> (which is also a good reason for soft forks to be backported btw)
19:32 < gmaxwell> Luke added the block proposal support so he could test daemon's block templates against each other.
19:32 < phantomcircuit> tulip, a TBV failure is 99% a mempool problem
19:32 < gmaxwell> But I'm not aware of any other pools using it.
19:32 < morcos> tulip: testblockvalidity failing means there is an error in block assembly logic, and its the fact that the consensus code is not borken that makes TBV say hey, this block is invalid
19:33 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
19:33 < morcos> if your mining software connected to .11.2 and .12.0   would it be smart enough to always get the new tip fast ala the .12.0 node or would you lose some of the speed advantages by having multiple?
19:33 < morcos> i guess maybe .11.2 could just be failover
19:34 < gmaxwell> morcos: right, which requires the 0.12 to stop if it fails; rather than, e.g. continue giving bad results and whining in logs.
19:34 < morcos> to be clear, i'm not particularly concerned that there is a bug in 0.12.0.  but i think that now we've changed the logic to require mempool consistency.  its inevitable that at some point in the future it'll have a bug
19:35 < gmaxwell> We've had consistency bugs in the past.
19:35 < morcos> hopefully one thats unlikely to be hit
19:36 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 250 seconds]
19:37 < gmaxwell> Perhaps we should have all full nodes doing a createnewblock every once in a while.
19:38 < gmaxwell> We're probably much less likely to get reports because so few users (and developers) mine.
19:39 < morcos> gmaxwell: i think the kind of bug that is most likely is a situation thats rare, such as a reorg that eliminated one sibling of a sequence locked tx whose fee rate was now too low and so would be evicted except RBF blah blah.  and when it happens its just going to happen to everyone.
19:40 < morcos> but having developers running at least one full node calling CNB all the time is worthwhile
19:40 < morcos> i've been doing that for a couple months now
19:40 < phantomcircuit> morcos, probably not since different maxmempool sizes
19:40 < phantomcircuit> even with the index usage in cnb in 0.12 i'd still have nodes with tiered max mempools
19:41 < gmaxwell> right. but, for example, we discourage mining on git master.  Now I mine on git master (well, 0.12 branch right now); but if there is any system dependency in the bug, I may not see it.
19:41 < gmaxwell> we've had bugs that were hit before only with debug options on, plausable we'll have one that is only hit with debug options off.
19:41 < phantomcircuit> gmaxwell, that could be part of making CNB run in a background thread continuously
19:42 < phantomcircuit> the gbt longpoll stuff does a good job of only running cnb when it's necessary
19:42 < morcos> i have a request, i'll direct if at gmaxwell since he runs the project now according to hearn
19:42 < phantomcircuit> (although there's a bug there around timing out normal http libs...)
19:42 < gmaxwell> phantomcircuit: yea, I think it could just do that for everyone. if you never call getblocktemplate it could just run with a 10 minute timer or whatever.
19:42 < morcos> before we can really make CNB run all the time and do many other improvements to the code
19:42 < phantomcircuit> gmaxwell, nah you just run it when there's a new block
19:42 < morcos> we need to rework the entire locking strategy
19:42 < gmaxwell> the locking train wreak you mean? :(
19:43 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.]
19:43 < morcos> exactly
19:43 < phantomcircuit> morcos, i suspect that's much more complicated than it initially sounds :P
19:43 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev
19:43 < morcos> we don't have to go to the perfect solution
19:43 < gmaxwell> Every time I go to add something where I need to add locking, I go to look to see how other things are locked.  And then I go looking for a bottle of stiff booze (well not really).
19:43 < morcos> but someone who is a better developer than i should draw up a road map for us 
19:44 < morcos> sipa had some good ideas for it, but maybe its not fair to give him every hard project
19:45 < gmaxwell> Sipa has been moving in a useful direction in new code, but I think he has not written down the principles that drives that direction enough to make it easy for the rest of us to predict the rest of the path for it.
19:46 < morcos> yeah.  i think overall the project would benefit from people working in a team fashion a bit more so workload could be divided.
19:46 < morcos> i'm happy to take direction
19:46 < morcos> maybe thats always hard to accomplish with open source
19:46 < phantomcircuit> gmaxwell, example?
19:47 < gmaxwell> phantomcircuit: look how the headers first, download tracking stuff works.
19:47 < morcos> i think there is a hesitation for sipa to right down those principles (or anyone else) b/c they don't want to be seen as telling everyone else that this is the way it is
19:47 < morcos> s/right/write/
19:47 < gmaxwell> "No please tell us what to do!"
19:48 < morcos> :)
19:48 < phantomcircuit> morcos, the cnb locking can be improved without too much hastle but requires acquiring cs_main and mempool.cs many many more times
19:48 < phantomcircuit> im not sure if that's worth it or not
19:48 < gmaxwell> I currently have code blocked on "need to fix locking".
19:49 < phantomcircuit> there's lots of random stuff where you need partial bits of the chain state but dont actually care if it changes since you're just going to sync against the changes immediately afterwards
19:49 < phantomcircuit> createnewblock being the most obvious
19:50 < phantomcircuit> there's also the wallet code but that's harder to reason aboue
19:50 < phantomcircuit> about*
19:50 < morcos> even just connecting a new block
19:50  * phantomcircuit goes to look at CNB in master
19:50 < phantomcircuit> morcos, lots of things devolve into "make chainstate an mvcc db"
19:50 < morcos> once you grab the state... you could release the lock to do all your validation..  and then grab it again to apply
19:50 < phantomcircuit> but complexity kills
19:50 < morcos> if the tip changed int he meantime, abort
19:51 < phantomcircuit> well there's things where copying the state is more expensive than the operation itself
19:51 < morcos> but connect block already grabs all the state it needs for the script verification threads
19:52 < morcos> it just waits for them to complete before flushing the new coinsview back to pcoinstip
19:52 < phantomcircuit> morcos, the particular case of the script verification queues is interesting
19:52 < morcos> there is no reason not to be accepting txs to your mempool during that time
19:52 < phantomcircuit> it should be easy to add another validation state
19:52 < morcos> as you only care about the old state consistency until the new state is applied and then you clean out the mempool for things which can't be there at that time anyway
19:53 < phantomcircuit> i tried but haven't touched that code enough to be confident it would work
19:53 < morcos> what do you mean another validation state?
19:53 < phantomcircuit> if we acquire the same lock twice in the same thread is that going to context switch?
19:53 < phantomcircuit> or deadlock?
19:54 < phantomcircuit> actually it's going to deadlock since they're not reentrant
19:54 < morcos> they are, which locks?
19:54 < phantomcircuit> morcos, "i've validated everything except the scripts"
19:54 < phantomcircuit> oh is cs_main reentrant?
19:54 < morcos> obviously to call ATMP and connect block concurrently you'd need to redesign the threads as well, since they're both almost always called by the same one
19:54 < phantomcircuit> oh they are
19:55 < morcos> ha, yeah, its pretty rare people bother to do assert_lock_held instead of just calling LOCK again
20:01 < phantomcircuit> do you need cs_main to use a CBlockIndex*
20:01 < phantomcircuit> ie chainActive.Tip() ?
20:03 < phantomcircuit> (im going to assume yes)
20:04 < morcos> thats the interesting question
20:04 < morcos> for the most part no
20:05 < phantomcircuit> morcos, it mostly doesn't matter actually
20:05 < phantomcircuit> it looks like you only need chainActive.Tip() for a small fraction of CNB runtime
20:05 < phantomcircuit> gmaxwell, do you know off hand the rough latency of LOCK(cs_main) ?
20:06 < morcos> phantomcircuit: remember if you lock it multiple times you're going to slow down the function b/c it'll have to keep waiting on the locks
20:07 < phantomcircuit> morcos, im going to change fBuildEmptyBlock to fNewBlock
20:07 < phantomcircuit> and change the locking strategy based on that
20:07 < morcos> are you referring to some existing PR
20:08 < phantomcircuit> https://github.com/bitcoin/bitcoin/pull/7104
20:10 < phantomcircuit> morcos, in general though i think we should be willing to give up the lock in CNB to allow for a new tip
20:11 < phantomcircuit> right now there's a problem where CNB can stall validating a new tip
20:12 < phantomcircuit> although this isn't in practice a huge problem since you reduce the average latency by n if you run n nodes
20:12 < phantomcircuit> divide*
20:12 < morcos> phantomcircuit: agreed, thats a problem.  but for now the non TBV part of CNB is fast enough that if we just solve for TBV that would be enough.
20:16 < phantomcircuit> morcos, we could run TBV without signature checking but everything being checked has is probably in sigcache
20:16 < phantomcircuit> so i dont see that making a huge difference
20:17 < Luke-Jr> TBV shouldn't be slow..
20:21 < GitHub0> [bitcoin] pstratem opened pull request #7203: Release cs_main in CreateNewBlock while selecting transactions from mempool. (master...2015-12-12-createnewblocklocks) https://github.com/bitcoin/bitcoin/pull/7203
20:21 < phantomcircuit> (note i haven't tested that PR like at all)
20:26 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
20:27 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
20:46 < morcos> phantomcircuit: ha, just thought of this.  when we call ConnectBlock from TBV we call it with fJustCheck.
20:46 < morcos> We should be able to release cs_main before control.Wait()
20:47 < morcos> so we don't have to wait for script verificaiton threads to finish with cs_main locked
20:47 < morcos> not sure exactly how much time that would save in general, but seems like a super easy win
20:51 < phantomcircuit> morcos, probably not much, remember that all the transactions being checked are already in sigcache
20:59 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
21:07 < sipa> phantomcircuit: not guaranteed :)
21:10 < phantomcircuit> sipa, it is when you run with the sigcache size i do :P
21:21 < gmaxwell> BlueMatt: have any way to estimate how long it takes for a transaction to reach all the relay node clients?
21:37 -!- bawong [~rich@c-50-184-106-81.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
21:42 -!- bawong [~rich@c-50-184-106-81.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]
22:04 < Luke-Jr> blah, gitian needs trusty now and that needs a vmbuilder upgrade :<
22:15 < tulip> that's weird, somehow my node has got into a state where it has fallen behind the chain.
22:15 < Luke-Jr> tulip: debug.log?
22:15 < tulip> "chain":"main","blocks":388132,"headers":388135
22:16 < tulip> Luke-Jr: nothing interesting, no rejects or invalid blocks, it's just chilling. 
22:16 < Luke-Jr> tulip: for how long?
22:16 < phantomcircuit> tulip, getpeerinfo
22:16 < phantomcircuit> i bet you're waiting for a peer to send you a block
22:17 < tulip> phantomcircuit: woo, there we go. socket timed out, and suddenly we're back at the tip after 26 minutes behind. 
22:18 < phantomcircuit> tulip, and that's why my gbt nodes connect to trusted nodes and the relaynetwork only
22:18 < tulip> sorry, an hour and 3 minutes behind. 
22:19 < CodeShark>  it takes over an hour to timeout a block request?!?!
22:19 < gmaxwell> no, it takes 20 minutes. 
22:19 < gmaxwell> but if you have multiple screwball peers you might time out more than once.
22:19 < gmaxwell> I know how to make it safely dynamic but haven't had a chance to implement it.
22:21 < gmaxwell> My thought for making it dynamic: start with the 20m timeout. When you sucessfully fetch a block measure how long the getdata took, extrapolate that to 1MB *2. Set the timeout to that.
22:21 < gmaxwell> Any time you kick a peer off for timing out, increase the timeout (1.5x?).
22:22 < gmaxwell> This should be safe and result in quite low timeouts for most peers most of the time.
22:22 < Luke-Jr> sounds gameable by hostile peers
22:23 < tulip> screwy network conditions caused this one but with alarmingly high amount of time where it sat knowing headers it couldn't update to. 
22:23 < Luke-Jr> keep connecting to your victim, and try to increase the timeout to a few days.. then trap real blocks, as you feed competing ones over a separate connection
22:24 < gmaxwell> Luke-Jr: Explain, because I think it's not usefully gamable (except by constant factors)
22:24 < gmaxwell> Luke-Jr: oh I assumed the timeout would still be capped at 20 minutes.
22:24 < Luke-Jr> oh, ok then
22:24 < gmaxwell> Beyond that, if you're actually that slow, you have no hope of keeping up with the network.
22:24 < CodeShark> in that case, shouldn't 10 min be the cap?
22:25 < Luke-Jr> CodeShark: nah, your connection might be bursty
22:25 < gmaxwell> CodeShark: No, because ^
22:25 < gmaxwell> there should be some headroom.
22:25 < Luke-Jr> might be reasonable to do some magic before the calibration though
22:26 < Luke-Jr> eg, if you don't get any traffic on the block within ~30 seconds, start getting it from another peer too and kick one if both start sending
22:26 < CodeShark> that's what I was sorta thinking
22:26 < Luke-Jr> otoh, a hostile actor may try to trickle it to you just to keep you downloading as slow as possible
22:26 < tulip> Luke-Jr: something is a bit ambiguous, if I want to slow you down I'll just send a byte a second. 
22:27 < Luke-Jr> tulip: yeah
22:27 < gmaxwell> Yea, that requires low level visibility that we don't really have right now.
22:27 < CodeShark> I was thinking we try from different peers and try to use the best one available - if one starts getting slow, we try others
22:28 < gmaxwell> CodeShark: requires having a concept of what 'slow' means, _and_ having sub-message visibility, .
22:28 < CodeShark> yes, we could check the buffer before we complete the download to get an estimate of the datarate
22:28 < gmaxwell> When we start the block fetch, there is always only one available (the first).
22:29 < CodeShark> we could also download multiple blocks in parallel from different peers when measuring download rate to not waste bandwidth
22:30 < Luke-Jr> CodeShark: fancy!
22:31 < Luke-Jr> but definitely more complicated to implement:P
22:31 < phantomcircuit> gmaxwell, has anybody analyzed how restrictions in bandwidth effect the probability that there has been a fork that you've not seen?
22:31 < gmaxwell> well there is only one block on the tip!
22:31 < phantomcircuit> i guess you'd see headers
22:46 < tulip> do nodes actually forward headers like that? 
22:46 < CodeShark> sync on core is headers-first
22:46 < CodeShark> which means you can validate PoW before downloading any actual blocks
22:47 < tulip> sure, but do nodes actively forward headers of blocks they don't believe to be the main chain
22:47 < CodeShark> oh, not that I'm aware of ;)
22:47 < CodeShark> not yet
22:48 < CodeShark> it's really expensive to create a competing chain that is invalid...so chances of such a chain growing long are low (unless something is fundamentally broken)
22:48 < Luke-Jr> tulip: if those nodes are attacking you, they do :D
22:49 < tulip> not invalid, just not best 
22:49 < CodeShark> such chains tend to die quickly
22:50 < CodeShark> the main threat with headers sync is the isolation attack
22:52 < CodeShark> having said that, it would be nice to have better fork detection capabilities...as in knowing that hashrate has forked
22:53 < CodeShark> which means something is fundamentally broken ;)
22:53 < tulip> forwarding all headers, always would be nice.
22:54 < tulip> that likely breaks assumptions though, I think the current p2p network assumes that if you inv a block you actually have it. 
22:57 < CodeShark> wasn't it suggested before that we stop inving blocks and just send block headers?
22:57 < gmaxwell> We could add a message that says "here is a header, but I don't have the block" but then you have to send a "I have the block" later.
22:57 < gmaxwell> CodeShark: yes, we do that now. but then the header is just the inv. :)
23:01 < CodeShark> we could just add a flag to the headers message
23:02 -!- davec_ [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Ping timeout: 272 seconds]
23:02 < CodeShark> might be a good idea to start versioning the p2p serialization structures separately from the client version and the consensus structure versions :)
23:04 < CodeShark> and to stop treating blocks as subclasses of block headers ;)
23:04 < gmaxwell> Versioning suggests linear progressions. :)
23:05 < CodeShark> versionbits for p2p? ;)
23:07 < CodeShark> the alternative is to just name the new p2p structures something else...which perhaps might be simpler in the end
23:09 < CodeShark> better fork detection would be a wonderful thing, though
23:11 < Luke-Jr> uh so
23:11 < Luke-Jr> I can no longer gitian-build :/
23:11 < Luke-Jr> vmbuilder fails on trusty
23:11 < Luke-Jr> what vmbuilder did other people here use?
23:13 < CodeShark> we could go beyond just "here is a header, but I don't have the block" - we could do "here's a header, I checked the block and it is invalid"
23:13 < gmaxwell> gavinandresen: Hi. I'm concerned that I keep hearing reports of you taking actions on behalf of Bitcoin Core while not actually communicating with anyone involved in the project, or being involved yourself. I wasn't sure of how much of this was rumor or miscommunication, but this appears to be you directly confirming it:
23:13 < gmaxwell> gavinandresen: https://www.reddit.com/r/btc/comments/3wj0du/gavin_we_want_to_donated_to_you/cxwx4hx
23:17 < GitHub178> [bitcoin] pstratem closed pull request #7203: [WIP][Mining]Release cs_main in CreateNewBlock while selecting transactions from mempool. (master...2015-12-12-createnewblocklocks) https://github.com/bitcoin/bitcoin/pull/7203
23:18 < GitHub101> [bitcoin] pstratem closed pull request #7150: Print size of pcoinsTip cache in AcceptToMemoryPool (master...2015-12-1-printcachesize) https://github.com/bitcoin/bitcoin/pull/7150
23:18 < GitHub115> [bitcoin] pstratem closed pull request #7104: [Mining] Build empty block on when chainTip changes. (master...2015-11-26-gbt-latency) https://github.com/bitcoin/bitcoin/pull/7104
23:18 < GitHub150> [bitcoin] pstratem closed pull request #7071: Wallet: Replace TxnAbort with assert. (master...2015-11-20-wallet-activetxn) https://github.com/bitcoin/bitcoin/pull/7071
23:18 < GitHub44> [bitcoin] pstratem closed pull request #7064: [Wallet]Perform entire CWallet::TopUpKeyPool in a transaction. (master...2015-11-19-wallet-topupkeypool) https://github.com/bitcoin/bitcoin/pull/7064
23:18 < GitHub180> [bitcoin] pstratem closed pull request #7057: Wallet: Flush database to log files (master...2015-11-18-wallet-flush) https://github.com/bitcoin/bitcoin/pull/7057
23:18 < GitHub101> [bitcoin] pstratem closed pull request #6874: Net: Cork socket send writes (master...msg_more) https://github.com/bitcoin/bitcoin/pull/6874
23:18  * Luke-Jr pokes phantomcircuit
23:18 < phantomcircuit> i wont be contributing to core anymore until the license is changed to prevent my work from being used by dickbags making backroom deals
23:18 < Luke-Jr> …
23:19 < Luke-Jr> phantomcircuit: you really think Core is going to become non-free software?
23:19 < phantomcircuit> Luke-Jr, no but i can certainly stop contributing
23:20 < Luke-Jr> phantomcircuit: you can, but all it's going to do is increase everyone else's workload :/
23:20 < GitHub38> [bitcoin] pstratem closed pull request #6943: Wallet: Store hash for encrypted keys (master...ckey_hash) https://github.com/bitcoin/bitcoin/pull/6943
23:20 < Luke-Jr> what's the point in making an ultimatum that you know cannot be met?
23:21 -!- Tera2342 [~Tera2342@171.5.144.9] has joined #bitcoin-core-dev
23:21 < phantomcircuit> Luke-Jr, the license can be changed to prevent specific people from using the code
23:22 < gmaxwell> phantomcircuit: I share your irritation, but you don't need to go pyrric on this; we'll take care about it.
23:22 < gmaxwell> er take care of it. :)
23:22 < Luke-Jr> phantomcircuit: not without it becoming non-free software, in which case I will have to quit Core and fork it.
23:22 < btcdrak> gmaxwell: it's time we boot gavinandresen 
23:23 < btcdrak> gavinandresen: you dont contribute to Bitcoin Core just to creating chaos. While others might be more polite, I'm going right ahead and saying this, please go away, you are not wanted here.
23:25 < gmaxwell> phantomcircuit: that people can take our work and use it in other projects is an important safty valve that guards against our own error, and frees us from having to accomidate every wish and desire; without creating lock in should we misstep.
23:25 < gmaxwell> phantomcircuit: so I think precluding people from exploiting out work, as 'just' and satisifying as it would be is not a good forward path.
23:27 < gmaxwell> s/out/our/
23:28 < CodeShark> if phantomcircuit is specifically referring to actions taken by someone on "behalf" of Bitcoin Core, I think the policy needs to be specifically directed at that...and we need to come out with one voice saying that someone doesn't represent Bitcoin Core
23:29 < Luke-Jr> I certainly wouldn't object to a joint statement. Changing the license to non-free is a big no-no IMO though.
23:29 < CodeShark> as to what the action could be, I'll leave that open to interpretation for now in the interest of being slightly more diplomatic than btcdrak
23:30 < gmaxwell> I really can't take the stress of the non-cooperative, backroom dealing, dram production and the attempts to undermine collaborative work anymore.
23:31 < gmaxwell> To say that I'm fed up with it would be an understatement, and attempts to address it in private have failed.
23:32 < midnightmagic> what is bitcoin's licence anyway.. mit/bsd?
23:32 < Luke-Jr> midnightmagic: yes
23:32 < midnightmagic> in magical parallel universe able-to-contact-everyone land, you could change it to gplv3
23:33 < Luke-Jr> midnightmagic: we could change it easily. MIT is relicensable to GPLv3
23:33 < Luke-Jr> but that wouldn't do what phantomcircuit is asking
23:33 < midnightmagic> mm. I don't think it is. That is, the original copyright is not alterable: only the copyright of modifications going forward, and those of people whom you've contacts and who agree in writing.
23:33 < gmaxwell> MIT is a reasonable choice for the basic infrastructure. Not having it that way would just encourage the creation of alternatives just for licensing sake, which would be preferable to avoid.
23:34 < btcdrak> gmaxwell: I dont think relicensing is the solution. I also dont think gavinandresen has a hope in hell gaining traction. XT was total failure and adoption of a hostile fork has been ruled out by miners and most major exchanges.
23:34 < aj> Luke-Jr: Affero GPL with code added to dump the running node's source via an RPC call could be hilarious though (iirc Affero GPL would prevent you from disabling/removing that feature)
23:34 < Luke-Jr> midnightmagic: only the new code going forward can be relicensed in any case; even if the old code were offered under a new license, the MIT license remains valid for it
23:35 < Luke-Jr> aj: it would need to be over p2p, not RPC
23:35 < Luke-Jr> aj: Eloipool uses it
23:35 < aj> Luke-Jr: quite right
23:35 < Luke-Jr> (and will dump its code over stratum or HTTP)
23:35 < gmaxwell> midnightmagic: phantomcircuit is unhappy that people who seem to be openly working against his own efforts trade on his work, and the name of the project. This is a downside of free software, but it's minor compared to the benefits.
23:36 < aj> Luke-Jr: easier to get at source for a python program than a c++ one too
23:36 < Luke-Jr> we could rename the project and enforce it as a trademark..
23:37 < btcdrak> Luke-Jr: "Bitcoin Core" as a phrase is probably trademarkable, but I really dont see the benefit.
23:37 < midnightmagic> gmaxwell: The number of netbsd core developers who have expressed raging bitterness just to me in private email that people like broadcomm make millions on their code and don't even contribute their modifications to the original source is more than I can count on one hand. And at the time they wrote me I was a nobody.. :-o
23:37 < Luke-Jr> btcdrak: but Hearn coined it
23:37 < Luke-Jr> in fact, is that a risk to us?
23:37 < gmaxwell> No.
23:37 < btcdrak> Luke-Jr: no
23:38 < midnightmagic> Does the U.S. have a pre-existing trademark exception rule too?
23:38 < midnightmagic> I know Canada does.
23:38 < Luke-Jr> midnightmagic: I think the GPL would be a bad choice for node software.
23:39 < btcdrak> The solution to gavin is what I said it was back in January when no-one would listen to me >.>
23:39 < midnightmagic> Luke-Jr: it would hinder its deployment probably. But, ignoring all that I don't think it's realistic anyway. Mostly navel gazing I guess.
23:39 < midnightmagic> btcdrak: I'm listening now. Can you link me?
23:40 < midnightmagic> In Canada, if you run a shop with a name of something that was trademarked *after* your use of the term, for as long as you operate you are excepted from trademark infringement. Unless the law has changed. Which is possible, given our recent experiment in neo-fascism.
23:41 < btcdrak> We need a technical lobbiest, someone who will go to companies and listen to them and discuss the technology with them. There are other things too, but I wont say them in public.
23:42 < midnightmagic> Well that was ideally what the BCF was supposed to do. :-/
23:42 < btcdrak> (because they would be used by gavin against us)
23:42 < btcdrak> The BCF is a useless train wreck.
23:42 < btcdrak> the BCF continues to prop up Gavin with the title "Chief Scientist" which gavin uses to mislead the companies he lobbies.
23:42 < Luke-Jr> problem: we are understaffed technically already..
23:43 < midnightmagic> I was optimistic (hope springs eternal) but I guess phantomcircuit pretty much called it ages ago when they first published the constitution.
23:44 < randy-waterhouse> btcdrak: did you specific companies in mind, or some examples?
23:44 < randy-waterhouse> s/did you have/
23:46 < btcdrak> randy-waterhouse: no, everyone in general. gavin and mike have gone around telling lies, the only way to counter that is to give taregetted presentations etc.
23:48 < Luke-Jr> btcdrak: not just a joint letter saying "you may have been told lies by <people>; we don't know what those lies are, so please take what was said with a grain of salt - we're here to clarify anything"
23:48 < Luke-Jr> ?
23:49 < btcdrak> Luke-Jr: Yes, we must actively say that. Bitcoin Core devs (as I have said repeatedly in private) are playing into the hands of disruption by being too politically correct and "nice". We need to be prepared to call a spade a spade.
23:49 < Luke-Jr> btcdrak: a letter is easier than a presentation, is what I mean.
23:50 < btcdrak> Luke-Jr: it's a good start,
23:50 < btcdrak> Luke-Jr: if I was a little richer I would pay someone but I have to preserve my funds because of my health situation which is questionable at the moment.
23:51 < Luke-Jr> btcdrak: hope your health improves :|
23:52 < btcdrak> Luje-Jr: yeah ditto! I wish they would find a diagnosis at least.