Rebase lbry on to Bitcoin 0.17. #266
No reviewers
Labels
No labels
area: devops
area: discovery
area: docs
area: livestream
area: proposal
consider soon
Epic
good first issue
hacktoberfest
hard fork
help wanted
icebox
Invalid
level: 0
level: 1
level: 2
level: 3
level: 4
needs: exploration
needs: grooming
needs: priority
needs: repro
needs: tech design
on hold
priority: blocker
priority: high
priority: low
priority: medium
resilience
soft fork
Tom's Wishlist
type: bug
type: discussion
type: improvement
type: new feature
type: refactor
type: task
type: testing
unplanned
work in progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: LBRYCommunity/lbrycrd#266
Loading…
Reference in a new issue
No description provided.
Delete branch "rc-rebase-0.17"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This contains significant rebase / merge / testing work by Naut
lbrynaut@protonmail.com, Anthony Fieroni bvbfan@abv.bg and Brannon
King countprimes@gmail.com.
@ -150,0 +152,4 @@
// NOTE: STALE_CHECK_INTERVAL is static that why we use raw value 10 * 60, sync may need in future
auto time = std::max({static_cast<int64_t>(10 * 60), 3 * consensusParams.nPowTargetSpacing});
braces?
Why is this removed?
This seems wrong; we don't want to count our held claims as available change.
I don't think we want this. We don't want to count our claims as spendable change. The old wallet didn't have it.
OpenSSL was removed from the core code. Every project should remove it.
Not sure what you mean. https://github.com/lbryio/lbrycrd/blob/legacy_master/src/wallet/wallet.cpp#L1152
https://github.com/lbryio/lbrycrd/blob/legacy_master/src/wallet/wallet.cpp#L1004
My bad. I was looking in the wrong spot.
@ -150,0 +152,4 @@
// NOTE: STALE_CHECK_INTERVAL is static that why we use raw value 10 * 60, sync may need in future
auto time = std::max({static_cast<int64_t>(10 * 60), 3 * consensusParams.nPowTargetSpacing});
Could be wrong, but I think this was a test @bvbfan worked on. In any case, std::max can take an initializer list, so there's really no difference (functionally) if they're removed other than style preference.
Pull request closed