1 2017-01-25 00:18:06	0|jtimon|periodical reminder that #8855 is rebase
 2 2017-01-25 00:18:14	0|gribble|https://github.com/bitcoin/bitcoin/issues/8855 | Use a proper factory for creating chainparams by jtimon · Pull Request #8855 · bitcoin/bitcoin · GitHub
 3 2017-01-25 00:23:50	0|gmaxwell|but does it use a factory factory singleton?
 4 2017-01-25 02:12:45	0|Chris_Stewart_5|what exactly is DEFAULT_BLOCK_PRIORITY_SIZE? Does this nodes will not relay blocks with low fee txs inside of it?
 5 2017-01-25 02:13:19	0|sipa|If nodes would choose to not relay valid blocks, they'd choose to be forked off.
 6 2017-01-25 02:13:26	0|sipa|it's a setting for the mining code
 7 2017-01-25 02:14:14	0|Chris_Stewart_5|sipa: Yeah I guess it seems bizarre, I figured logic with building blocks would just be some sort of greedy algo and that would implicitly be enforced
 8 2017-01-25 02:14:25	0|Chris_Stewart_5|unless there were no high fee txs
 9 2017-01-25 02:14:40	0|sipa|Chris_Stewart_5: that's what we're doing in practice
10 2017-01-25 02:14:59	0|Chris_Stewart_5|I guess why do we need the constant then?
11 2017-01-25 02:15:39	0|sipa|but there is a legacy mining algorithm that uses BTC_days_destroyed per byte (confusingly named priority) as sorting criteria instead of feerate
12 2017-01-25 02:16:17	0|sipa|the DEFAULT_BLOCK_PRIORITY_SIZE value gives the default setting for -blockprioritysize (which defaults to 0), which sets the bytes of blockspace assigned to that algorithm
13 2017-01-25 02:17:21	0|Chris_Stewart_5|Interesting, thanks. So before a fee market was around we would favor old coins being spent for block inclusion instead of new ones?
14 2017-01-25 02:18:24	0|sipa|yup
15 2017-01-25 02:20:27	0|Chris_Stewart_5|Cool. Thanks! Always interesting to learn historical contexts around decisions.
16 2017-01-25 04:03:15	0|bitcoin-git|[13bitcoin] 15jtimon opened pull request #9627: Remove extra nonce reset logic in IncrementExtraNonce (06master...06upstream-elements-unused-extranonce) 02https://github.com/bitcoin/bitcoin/pull/9627
17 2017-01-25 04:15:48	0|luke-jr|jl2012: I think anti-replay isn't something specifically needed for HFs. need it without a HF in some cases too
18 2017-01-25 05:15:55	0|jl2012|luke-jr: for example?
19 2017-01-25 05:19:59	0|luke-jr|Tx A=UTXO 1 used to pay 1someaddress2 (no change); Tx B=UTXO 1 and UTXO 2 used to pay 1someaddress2 and 1someaddress3 (no change; double-spend of Tx A); Tx A is mined; 1someaddress3 still needs to be paid, but there is no way to guarantee Tx A won't reorg out.
20 2017-01-25 05:33:51	0|jl2012|Just use the output of TxA to pay
21 2017-01-25 05:34:51	0|jl2012|Oh, no change
22 2017-01-25 05:36:09	0|jl2012|Just use UTXO2 to pay someaddress3
23 2017-01-25 05:48:50	0|luke-jr|jl2012: ok, but I think there are rare cases where there isn't such a solution :p
24 2017-01-25 05:54:07	0|luke-jr|Chris_Stewart_5: btw, note that priority sorting is not strictly historical, and is still is use by some miners.
25 2017-01-25 06:10:01	0|gmaxwell|luke-jr: what miner?
26 2017-01-25 14:36:16	0|bitcoin-git|[13bitcoin] 15sdaftuar opened pull request #9628: qa: Increase a sync_blocks timeout in pruning.py (06master...062017-01-longer-pruning-sync) 02https://github.com/bitcoin/bitcoin/pull/9628
27 2017-01-25 15:17:25	0|BlueMatt|cfields: re: #9609 yea, I know you dont want to use fSuccessfullyConnected in net_processing after 0.14, but its so much cleaner to use that appropriately now and split it out into CNodeState in 0.14, so i figured I'd suggest it :)
28 2017-01-25 15:17:27	0|gribble|https://github.com/bitcoin/bitcoin/issues/9609 | net: fix remaining net assertions by theuni · Pull Request #9609 · bitcoin/bitcoin · GitHub
29 2017-01-25 16:16:05	0|cfields|BlueMatt: i tried hard to disagree but couldn't :)
30 2017-01-25 16:17:01	0|cfields|I do want something net-only going forward, but I'll do that next. Once we're forked, I have a flood of changes. I'll just pile that on.
31 2017-01-25 16:19:23	0|BlueMatt|heh, ok
32 2017-01-25 16:22:07	0|cfields|gmaxwell: are you ok with that? I see you acked as-is, but I think BlueMatt's suggestion only locks us down tighter
33 2017-01-25 16:22:40	0|cfields|note that it is a change in p2p behavior though. Pretty sure the current network allows for not sending a VERACK with not much downside
34 2017-01-25 16:22:59	0|cfields|(other than obviously not getting new serialization)
35 2017-01-25 16:23:54	0|BlueMatt|I'd hope we consider that undefined behavior?
36 2017-01-25 16:24:16	0|cfields|i would certainly say so
37 2017-01-25 16:24:36	0|cfields|i think the only quasi-valid real-world change would be addr races
38 2017-01-25 16:25:21	0|BlueMatt|have we ever sent addr messages before verack?
39 2017-01-25 16:25:50	0|BlueMatt|I mean I know we can send shit before verack on accident, but all of that stuff would otherwise just not be sent
40 2017-01-25 16:27:08	0|cfields|not us, i meant other nodes maybe sending verack/getaddr out of order
41 2017-01-25 16:30:03	0|BlueMatt|ehh, if they send it out of order I'm happy to not resrpond
42 2017-01-25 18:28:49	0|bitcoin-git|[13bitcoin] 15jtimon closed pull request #9627: Remove extra nonce reset logic in IncrementExtraNonce (06master...06upstream-elements-unused-extranonce) 02https://github.com/bitcoin/bitcoin/pull/9627
43 2017-01-25 18:46:13	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #9630: Add logging to GetAncestor if pindex->pprev == NULL (06master...06crashlogging) 02https://github.com/bitcoin/bitcoin/pull/9630
44 2017-01-25 18:46:17	0|wallet42|are the slides from jl2012 from Shanghai (about consensus) online somewhere?
45 2017-01-25 18:50:46	0|moli|wallet42, wrong channel
46 2017-01-25 21:53:31	0|bitcoin-git|[13bitcoin] 15isle2983 opened pull request #9632: Add clang_static_analysis.py to help automate static analysis runs (06master...06PR-clang-static) 02https://github.com/bitcoin/bitcoin/pull/9632
47 2017-01-25 23:23:12	0|CubicEarth|The biggest issue I'm aware of with lightning is the 'bank run' scenario, with not enough on-chain capacity for people to dispute fraud before the block-window closes, as could be the case if a hub tried to steal funds from millions of people. Am I understanding correctly this is an issue? Is there a viable solution?
48 2017-01-25 23:24:12	0|sipa|not sure this is the best place to discuss it, but i think that is the main reason why we shouldn't accept very large hubs
49 2017-01-25 23:27:14	0|CubicEarth|sipa: thanks. what's the better place for this topic?
50 2017-01-25 23:27:49	0|sipa|lightning mailing list, perhaps?
51 2017-01-25 23:29:01	0|gwillen|CubicEarth: there is a #lightning-dev channel
52 2017-01-25 23:29:06	0|gwillen|it's not super active but the right people are there
53 2017-01-25 23:30:17	0|CubicEarth|sipa: gwillen: √
54 2017-01-25 23:31:12	0|gmaxwell|CubicEarth: there are proposals that reduce that exposure, e.g. timestop.. where CSV's counting is not monotone but can slow down when the network is full of high fees.  But it's not really needed for basic operation of the system.
55 2017-01-25 23:34:38	0|CubicEarth|gmaxwell: cool. I'll read up.
56 2017-01-25 23:38:07	0|gmaxwell|I don't know if there is much of a writeup of timestop beyond the observation that CSV clock doesn't have to tick once per block.. we setup the CSV spec so there is extra room to signal other kinds of ticking.
57 2017-01-25 23:38:30	0|gmaxwell|Joseph poon had some ideas on particular incentive compatible timestop schemes but it hasn't had a lot of research.
58 2017-01-25 23:42:20	0|CubicEarth|It seems like something that needs to be solved or with time, systemic risk will develop
59 2017-01-25 23:44:59	0|CubicEarth|g2g ... ttyl