To avoid confusion with old or development issues I’ve started a new thread, for web site and forum developments.
http://forum.feathercoin.com/topic/8895/dev-feathercoin-web-site-forum-issues-and-improvement
@wrapper said in [Dev] Release Candidate Feathercoin 0.9.3.2 - Check List:
The level of dust payment / minimum transaction level fee is ridiculously high 1% this seems to be for historical “reasons”, like encouraging high value transactions.
So, for instance, what is the point of having mFTC and uFTC when they pay 1000% fee?
I propose min fee is moved to 0.001 FTC,
The main problem with this is mFTC has 100%fee, when smart contracts come in they might be under priced :
We can enforce a higher fee for smart contracts, i.e they will have 2 parts,
rejestering the contract - 0.01 min : pay a extra fee to speed up.
running the contract : pay a contract fee 0.01 min - pay extra to speed up
http://bitcoin.stackexchange.com/questions/24869/1-500-transaction-fee-and-3-5-months-to-confirm
The transaction fee is payed to the miners finding a block. The idea behind it is, that after all coins habe been mined, we still need to give miners an intensive to mine, and that there will be a sufficient number of transactions per block, so that the cost of mining is covered.
If we lower the fee, we mFTC and µFtC transactions are not overpaid, but we may face problems with a constantly low hashrate.
You are right, the server may not be necessary in the long run. I’d still like to have an official build of the various packaging systems, e.g. docker etc
Once (auto) build services are up (for the packaging technologies like snappy) it should be easier to get less technical members help maintain those and just report when problems occur.
I found Gitian interesting, but had to give up trying to convert the FTC mobile wallet to it after a number of weeks trying.
This means we need to build the Bitcoin Mobile wallet, pull in changes from Bitcoin, and that will be set up ready to apply our own patches to make that a FTC mobile wallet build.
One interesting thing I saw using 0.9.6 is appearance of very small transaction fees. If using 0.8.7 I had 0.02 or 0.14 FTC now I can get 0.0000012 for example. Would like to know about this more, or link where to read. Thanks!
When I fixed the 0.9.6 tests I had a look at the code for Bitcoins 0.11 tests, there’s a few things that have changed so I doubt any of my test fixes will work for 0.11…not 100% sure tho.
As long as the data used is the same, it should be ok.
I also came across this wallet that can store and exchange FTC. Still going, interesting if anyone tried it.
Coinomi Bitcoin Altcoin Wallet
https://play.google.com/store/apps/details?id=com.coinomi.wallet&hl=en_GB
https://coinomi.com/
@Aciddude I agree with your comments.
The probability is we will move all development to 0.11 and just the stub (0.9.7-dev), without the “release specific changes” will remain.
Hopefully most issues can be fixed in 0.11.
We can get a feel for how quickly 0.11 can be audited for release, will depend on the number of changes to bring across etc. Obviously, the quicker we can do that the less likely further developments in 0.9.x …
Thanks @Aciddude for compiling an update on all the work you’ve done researching binary signing.
The links and discussion will be useful for other developers with the same issues. We have serious issue of defining which is our release version, I see binary signing, and the way we allocate that, as essential for ongoing security of the core FTC wallet.
Gitian
I like the Gitian idea, we can use the Launchpad build to be the same as the OpenSuse build to prove our binaries. It’s another good reason to get the Ubuntu PPA / build on Launchpad set up.
Bitcoin security warning
https://bitcoin.org/en/alert/2016-08-17-binary-safety
I’m going to get this set up and tested on my feathercoin fork and once we have builds going out for all the major OS’s well definitely give confidence in the code
You have to allow a “Travis-ci” app access to your code repo in github…this is why I wanna try it on my fork, write down the instructions and then maybe @Wellenreiter can do it for Feathercoin ?
@Wellenreiter said in [DEV] MacOS - Build Feathercoind + Feathercoin-Qt v0.9.3.1 [COMPLETED]:
@lizhi, @aciddude
Thanks for that.
Can you provide the binaries, when we officially release 0.9.6?
I’m happy to provide OSX Binaries
Using the makefile to diagnose Feathercoin source code build problems
As part of testing the builds and build instructions, sometimes there are problems with different GNU/Linux distributions or other OS compiles. Even where it worked fine before, the OS can suddenly require a special version of some software and change a dependency.
With FTC problems can happen with, QR code / zxing and SSL or encryption libraries.
The other problem is just errors in copying and pasting where, say, you home directory or the position of a specially compiled binary needs to be specified.
Following the guide to compile Feathercoin, untill ./configure.
http://forum.feathercoin.com/topic/8556/guide-ubuntu-16-04-lts-build-feathercoind-feathercoin-qt-v0-9-3-1
The “makefile” is then created and can be examined, in particular, directory pointers :
LRELEASE = /home/wrapper/anaconda2/bin/lrelease
LTLIBOBJS =
LUPDATE = /home/wrapper/anaconda2/bin/lupdate
MAINT =
MAKEINFO = ${SHELL} /home/wrapper/Feathercoin/src/build-aux/missing makeinfo
MAKENSIS =
As can be seen in this case, lupdate was pointing to the wrong directory, due to a previous anaconda install. That value can be temporary corrected before running the “make” command to do the actual compile to produce a binary.
I just saw this,
I did something similar
https://github.com/aciddude/Feathercoin/commit/35e34280cf929d086e72e9d3ac6719c8a2fdd559
to get 0.9.3.1 to build on OSX with the latest boost 1.62.0
I also had to build boost from source, see the 2nd post here:
http://forum.feathercoin.com/topic/8769/guide-build-feathercoind-feathercoin-qt-v0-9-3-1-on-macos-sierra/2
The fixes are mainly to the build instructions and finish running all the automatic tests.
It’s worth setting up a test build environment, there should be no issues with any of the versions. It’s worthwhile to have test builds on any Linux distro or other OS like BSD as well, where there have been builds in the past.
