Update base version to 0.18.x #72
No reviewers
Labels
No labels
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Core-Wallets/monacoin!72
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "junkey-dev-0.18"
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?
Just rebased master-0.17 onto litecoin/0.18. It have not been
built andtested yet.[FYI] What I did.
I suppose this way is one of the easiest way.
[FYI] I'll push my commits with
--forceinto this PR branch until it was merged.Please have in mind if you track this.
The minimum build (monacoind with '--without-wallet`) was passed.
QT has not been tried yet.
Of course, this doesn't mean "binaries from this tree are stable."
I'm trying full build and found build errors. I'm going to fix them. The workaround is
configure --without-walletfor now.If I find a better place to change, should I write it here?
@wakiyamap Nice catch. I did it and pushed.
I force pushed commits here. I believe
monacoin-walletcan be built now.@ -19,1 +18,3 @@elseif (nSize > 0) {__int128_t n = (__int128_t)nFeePaid * 1000 / nSize;assert(n <= INT64_MAX);If value of
nFeePaidis 10512000000000000(MAX_MONEY), it's overflow?nFeePaid * 1000 =
10,512,000,000,000,000,000int64_t of max is
9,223,372,036,854,775,807So......how about adding the following?
assert(nFeePaid<= MAX_MONEY);Personaly, I'd like to believe that maybe this isn't the case.
I could build it. yay!!
@ -0,0 +49,4 @@Create new wallet file.IPinfo.IPMonatcoin -> Monacoin
Litecoin -> Monacoin
src/config/bitcoin-config.h
src/Makefile
@ -0,0 +49,4 @@Create new wallet file.IPinfo.IPNice catch! I fixed it.
@wakiyamap I see. They should be fixed
AC_INITinconfigure.ac. I did it and pushed here.@ -19,1 +18,3 @@elseif (nSize > 0) {__int128_t n = (__int128_t)nFeePaid * 1000 / nSize;assert(n <= INT64_MAX);x
assert(nFeePaid <= MAX_MONEY);o
assert(nFeePaid <= INT64_MAX / 1000);MAX_MONEYis niet goed genoeg.There is a python module called monacoin_scrypt in the source.
Should I have monacoin_scrypt in pypi?
Ex.. https://pypi.org/project/litecoin_scrypt/
@wakiyamap
lyra2re2_hash, I thought.......
But, If we're just testing, maybe scrypt is the way to go.
@wakiyamap I grepped in the branch.
And I found
monacoin_scryptrelated code in.travis.ymland `test/functional/test_framework/messages.py'In
.travis.yml, we don't need to care because$MONACOIN_SCRYPTwon't set to1.IMO,
message.pywill be useless now even if the PIP module was applied. Totally tests have been broken.I agree that tests should be refactored for Monacoin. Someday we could do it.
But code in this branch will have similar quality to the released code even if we didn't refactor.
@ -19,1 +18,3 @@elseif (nSize > 0) {__int128_t n = (__int128_t)nFeePaid * 1000 / nSize;assert(n <= INT64_MAX);Is this a good practice to use
asset()here?I suppose all Monacoin-core nodes will be aborted by assertion failed.
assert()in current code is checks for the runtime (compiler) limitations. Not for argument checks.My alternative plan is to use
int128_tand/oruint128_tin functions. WDYT?@cryptcoin-junkey
ok. I agree. I think it's not necessary to all test it ""now"".
This is fine for the base(0.18.x).
But if we're going to release it, please just add
maxfeerate.@ -19,1 +18,3 @@elseif (nSize > 0) {__int128_t n = (__int128_t)nFeePaid * 1000 / nSize;assert(n <= INT64_MAX);It's good.
I'm not very familiar with C++, but it looks like it says you have to use
BOOST.If you're putting in a new library, so......is it better to use
arith_uint256?@ -19,1 +18,3 @@elseif (nSize > 0) {__int128_t n = (__int128_t)nFeePaid * 1000 / nSize;assert(n <= INT64_MAX);...fm
nFeePaid * 1000 = 10,512,000,000,000,000,000
max of uint64_t = 18,446,744,073,709,551,615
so,
How do you think?
@ -19,1 +18,3 @@elseif (nSize > 0) {__int128_t n = (__int128_t)nFeePaid * 1000 / nSize;assert(n <= INT64_MAX);How about fixing the type of
CAmount?In
src/amount.h:It looks this was discussed in the bitcoin core team.
They didn't need it. And it may be worth to consider for us.
@ -19,1 +18,3 @@elseif (nSize > 0) {__int128_t n = (__int128_t)nFeePaid * 1000 / nSize;assert(n <= INT64_MAX);Ooops,
s/int128_t/__int128_t/. AFAIK,__int128_tis GCC extension, supported by Clang also.@ -19,1 +18,3 @@elseif (nSize > 0) {__int128_t n = (__int128_t)nFeePaid * 1000 / nSize;assert(n <= INT64_MAX);Another plan. I guess this plan is safer.
@ -19,1 +18,3 @@elseif (nSize > 0) {__int128_t n = (__int128_t)nFeePaid * 1000 / nSize;assert(n <= INT64_MAX);@cryptcoin-junkey
I disagree with setting CAmount to
int128_t.The impact is toooooooooo great.
I agree to an another plan.
[English]
Why not decide on the criteria to release?
The overflow fix is complete, etc......
My suggestion.
As soon as the overflow fix is complete, run it on your own node for a month or so and release it if it's OK.
[日本語]
リリースする基準を決めませんか?
オーバーフローの修正が完了したら等……
私としてはオーバーフローの修正が完了して、1か月ほど各自でノードを運用して問題なければリリースで良いかなと思います。
I pushed the fix against #76.