< gmaxwell>
but does it use a factory factory singleton?
< Chris_Stewart_5>
what exactly is DEFAULT_BLOCK_PRIORITY_SIZE? Does this nodes will not relay blocks with low fee txs inside of it?
< sipa>
If nodes would choose to not relay valid blocks, they'd choose to be forked off.
< sipa>
it's a setting for the mining code
< 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
< Chris_Stewart_5>
unless there were no high fee txs
< sipa>
Chris_Stewart_5: that's what we're doing in practice
< Chris_Stewart_5>
I guess why do we need the constant then?
< sipa>
but there is a legacy mining algorithm that uses BTC_days_destroyed per byte (confusingly named priority) as sorting criteria instead of feerate
< 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
< 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?
< sipa>
yup
< Chris_Stewart_5>
Cool. Thanks! Always interesting to learn historical contexts around decisions.
< bitcoin-git>
[bitcoin] jtimon opened pull request #9627: Remove extra nonce reset logic in IncrementExtraNonce (master...upstream-elements-unused-extranonce) https://github.com/bitcoin/bitcoin/pull/9627
< luke-jr>
jl2012: I think anti-replay isn't something specifically needed for HFs. need it without a HF in some cases too
< jl2012>
luke-jr: for example?
< 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.
< jl2012>
Just use the output of TxA to pay
< jl2012>
Oh, no change
< jl2012>
Just use UTXO2 to pay someaddress3
< luke-jr>
jl2012: ok, but I think there are rare cases where there isn't such a solution :p
< luke-jr>
Chris_Stewart_5: btw, note that priority sorting is not strictly historical, and is still is use by some miners.
< gmaxwell>
luke-jr: what miner?
< bitcoin-git>
[bitcoin] sdaftuar opened pull request #9628: qa: Increase a sync_blocks timeout in pruning.py (master...2017-01-longer-pruning-sync) https://github.com/bitcoin/bitcoin/pull/9628
< 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 :)
< cfields>
BlueMatt: i tried hard to disagree but couldn't :)
< 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.
< BlueMatt>
heh, ok
< cfields>
gmaxwell: are you ok with that? I see you acked as-is, but I think BlueMatt's suggestion only locks us down tighter
< 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
< cfields>
(other than obviously not getting new serialization)
< BlueMatt>
I'd hope we consider that undefined behavior?
< cfields>
i would certainly say so
< cfields>
i think the only quasi-valid real-world change would be addr races
< BlueMatt>
have we ever sent addr messages before verack?
< BlueMatt>
I mean I know we can send shit before verack on accident, but all of that stuff would otherwise just not be sent
< cfields>
not us, i meant other nodes maybe sending verack/getaddr out of order
< BlueMatt>
ehh, if they send it out of order I'm happy to not resrpond
< bitcoin-git>
[bitcoin] jtimon closed pull request #9627: Remove extra nonce reset logic in IncrementExtraNonce (master...upstream-elements-unused-extranonce) https://github.com/bitcoin/bitcoin/pull/9627
< bitcoin-git>
[bitcoin] jnewbery opened pull request #9630: Add logging to GetAncestor if pindex->pprev == NULL (master...crashlogging) https://github.com/bitcoin/bitcoin/pull/9630
< wallet42>
are the slides from jl2012 from Shanghai (about consensus) online somewhere?
< moli>
wallet42, wrong channel
< bitcoin-git>
[bitcoin] isle2983 opened pull request #9632: Add clang_static_analysis.py to help automate static analysis runs (master...PR-clang-static) https://github.com/bitcoin/bitcoin/pull/9632
< 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?
< 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
< CubicEarth>
sipa: thanks. what's the better place for this topic?
< sipa>
lightning mailing list, perhaps?
< gwillen>
CubicEarth: there is a #lightning-dev channel
< gwillen>
it's not super active but the right people are there
< CubicEarth>
sipa: gwillen: √
< 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.
< CubicEarth>
gmaxwell: cool. I'll read up.
< 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.
< gmaxwell>
Joseph poon had some ideas on particular incentive compatible timestop schemes but it hasn't had a lot of research.
< CubicEarth>
It seems like something that needs to be solved or with time, systemic risk will develop