project-bitmark / bitmark Goto Github PK

Using the latest version of Mac OS I got this error after ./autogen.sh && ./configure --with-boost-libdir=/usr/local/Cellar/boost/1.63.0/lib && make

net.cpp:1067:15: error: no matching function for call to 'upnpDiscover'
devlist = upnpDiscover(2000, multicastif, minissdpdpath, 0, 0, &error);
^~~~~~~~~~~~
/usr/local/include/miniupnpc/miniupnpc.h:62:1: note: candidate function not viable: requires 7 arguments, but 6 were provided
upnpDiscover(int delay, const char * multicastif,
^
1 error generated.

So I opened my text editor and edited that line to devlist = upnpDiscover(2000, multicastif, minissdpdpath, 0, 0, 0, 0);

After that edit the compile worked although I didn't actually go read the upnpDiscover code so I have no idea what I did.

With the current implementation there is not enough memory (at least for some 32 bit systems) to allocate statically and it must be dynamically allocated (heap). Solution: bitmarkcc@16b949e.

Update the sha sums of intermediaries in build process after openssl upgrade

Hi,

I'm running Bitmark-Qt-HighSierra_0.9.7.1-RC1.dmg and can't get my blockchain to sync.

My /Volumes/LaCie/AppSupport/Bitmark/debug.log file is full lines like the following:
2018-06-24 18:17:09 connect() to 127.0.0.1:9050 failed after select(): Connection refused (61)
2018-06-24 18:17:10 connect() to 127.0.0.1:9050 failed after select(): Connection refused (61)
...
2018-06-24 18:17:11 connect() to 127.0.0.1:9050 failed after select(): Connection refused (61)

Any idea what I can do to get passed this? I had the same problem is the previous version.

Thanks,
~Johnny

When I downloaded and ran bitmarkd (v0.9.7.0), I ran into

bitmarkd: error while loading shared libraries: libboost_system.so.1.58.0: cannot open shared object file: No such file or directory

Could I get some help on debugging this?

Bitmark has a unique history, one of fairness, of utility, and one with a vision for a powerful use case, namely web scale marking

However, due to a combination of bad luck with miners and exchanges among other things, we have fallen below our potential

When people look at alt coins they think of exit scams, of founders getting rich, ICOs, dev taxes, premines and instamines. We did none of those things, and in fact, was one reason that our early years have been that much harder

How do we explain to people that this coin is different. ie that it is not a "sh*tcoin", as that will be the first question that anyone new to the project will likely ask. I also hear the concern raised that the coin is dominated by whales, however the price low enough right now and has been a while that anyone can buy a decent chunk

I suggest putting together a history from the genesis block, where we were released without any unfair advantages, of the early years and running out of resources, then the recovery, and poloniex troll box delivered to almost a million users. Then the miner attacks of famine and feast, followed by selfish mining rerogs. Followed by the fork discussion. Why it was done in a certain way. Then the cryptopia story. Until the current day where we are now

I wonder can we turn this and other points into part of a FAQ or something that we can put on the wiki or on the home page?

Related to some other issues, I'm unable to make on Ubuntu 20.04

bignum.h:594:77: error: cannot convert ‘const CBigNum*’ to ‘const BIGNUM*’

I believe this is related to openssl, but didnt work out how to fix it

Also, I'm doing final testing on development v0.9.7.5, which implements the "headers first, blocks-in-parallel" initial blockchain download (IBD/HF-BIP) strategy which debuted in bitcoin v0.10 This enables faster initial blockchain download, because only the block headers are initially obtained from a single peer; once the entire chain of headers is obtained and verified as correct, then the actual block data for each block is filled in, from several peers in parallel, concurrently.

from @dbkeys in #103

Let's discuss this here. It seems it should be on hold until v.0.9.7.4 is working and the proposal is written up and reviewed, PRs associated with the issue, etc. Let's stop merging into master before review after v.0.9.7.4, please

I've compiled bitmarkd from source on ubuntu 16.04 and tried to sync blockchain, but sync got stuck on block 450627. Part of the log:

UpdateTip: new best=9df459786d64f926e91ac357146e0a11b78fb8d4e70bf2cc10943434a936f528 height=450627 log2_work=72.835175 tx=1089800 date=1526090544 progress=0.712616 nbits=456215360 algo=0
ProcessBlock: ACCEPTED
Requesting block 1ee33a0c2faa5795f82c33d79e1f5809608f11a399b0d23447e9de82632da27b from 139.162.128.92:9265
sending: getdata (37 bytes)
sending: inv (37 bytes)
received: block (1700 bytes)
received block c08f9fa005400ffbd0f750b5e3c67d0bf79674e9b9343ba88cbd62f2a3442481
ERROR: CheckTransaction() : vout empty
ERROR: CheckBlock() : CheckTransaction failed
ERROR: ProcessBlock() : CheckBlock FAILED
Requesting block f6c734f3bd176651f7e9e3d22a7577dafb575dce8c365ca38af488668de1d752 from 139.162.128.92:9265
sending: getdata (37 bytes)
received: block (7347 bytes)
received block c60a4a65d0dd66cabbd56722d6d4ffb0126674e878641f30638e4f06e061d1e3
check auxpow err 1
ERROR: AuxPow is not a generate
auxpow err 5
ERROR: CheckAuxPowProofOfWork : AUX POW is not valid
ERROR: CheckBlock() : auxpow proof of work failed
ERROR: ProcessBlock() : CheckBlock FAILED
received: block (9376 bytes)
received block 44450bff453b2f67782fa2ffd0a53aca3e7ab5d65a8c04f570209be25ee4f9fa
ERROR: CheckBlock() : size limits failed
ERROR: ProcessBlock() : CheckBlock FAILED
received: block (7684 bytes)
received block 18fae94924efeb2b28e08384f4f6b4fc4673f5b72ad0c48bca812f46d3988907
ERROR: CheckProofOfWork() : nBits below minimum work
ERROR: CheckBlock() : proof of work failed
ERROR: ProcessBlock() : CheckBlock FAILED
received: block (213 bytes)
received block f973da5bfd02e44d99236aa255d24f37a7c3ad905c2d4ffad296e31ae24ded06
ERROR: CheckBlock() : size limits failed
ERROR: ProcessBlock() : CheckBlock FAILED
received: block (91 bytes)
received block 478bac48864a27b6ff87f9a91faf84039388da0cf8b6afe0a9c653172ff13cdc
ERROR: CheckProofOfWork() : nBits below minimum work
ERROR: CheckBlock() : proof of work failed
ERROR: ProcessBlock() : CheckBlock FAILED
received: block (7221 bytes)
received block 880f5dd6b2010f17bd457649326df77fefc86353073cd6666a5209c8ea920b78
ERROR: CheckProofOfWork() : nBits below minimum work
ERROR: CheckBlock() : proof of work failed
ERROR: ProcessBlock() : CheckBlock FAILED
received: block (7308 bytes)
received block bda77e701135bad77b87e4dfa8df84a0d1c220c4d898815679d4df0a070a981d
ERROR: CheckProofOfWork() : nBits below minimum work
ERROR: CheckBlock() : proof of work failed
ERROR: ProcessBlock() : CheckBlock FAILED
received: block (14037 bytes)
received block 5578fecf8f6511bab1216da42694deec24cc7b53e788bee9510b87a36c0f134b
ERROR: CheckBlock() : size limits failed
ERROR: ProcessBlock() : CheckBlock FAILED
received: block (19691 bytes)
received block 8dade054a23459eb1688a6d296a20fd1f5eab40a5662e764cb6024879affc3f1
ERROR: CheckProofOfWork() : nBits below minimum work
ERROR: CheckBlock() : proof of work failed
ERROR: ProcessBlock() : CheckBlock FAILED
received: block (172 bytes)
received block 4c70ebda2df275c9dd2d152ab2b9968e3a2cc32af0c3114a9ebb5eaa2710716c
ERROR: CheckBlock() : size limits failed
ERROR: ProcessBlock() : CheckBlock FAILED
received: block (8417 bytes)
received block 99f4d77fefff4fa76c404b3ba6f5f99b5a5cc40df16669ff2c609a7e2031db5a
check auxpow err 1
ERROR: AuxPow is not a generate
auxpow err 5
ERROR: CheckAuxPowProofOfWork : AUX POW is not valid
ERROR: CheckBlock() : auxpow proof of work failed
ERROR: ProcessBlock() : CheckBlock FAILED
received: block (11123 bytes)
received block 47986fd13d63ce2aa0e87bf3826739cae3cd9a45bb88f9fce7d0efedeca16e50
ERROR: CheckProofOfWork() : nBits below minimum work
ERROR: CheckBlock() : proof of work failed
ERROR: ProcessBlock() : CheckBlock FAILED
received: block (208 bytes)
received block b6a70fc6845f878546cb916e201e8df644d0ac4b2597d686a6e6400c64644773
ERROR: CheckBlock() : size limits failed
ERROR: ProcessBlock() : CheckBlock FAILED
received: block (39299 bytes)
received block a87cf133d4c6b74e1a03f7718f33a810a17ec2e1f7de7cf4fc4decfcce2c60aa
check auxpow err 1
ERROR: AuxPow is not a generate
auxpow err 5
ERROR: CheckAuxPowProofOfWork : AUX POW is not valid
ERROR: CheckBlock() : auxpow proof of work failed
ERROR: ProcessBlock() : CheckBlock FAILED
received: block (11337 bytes)
received block 5fa092b1844aa839ba894f8cb81d0dc29ed4da4c7aaade6319ff9f1f465ff71a
ERROR: CheckProofOfWork() : nBits below minimum work
ERROR: CheckBlock() : proof of work failed
ERROR: ProcessBlock() : CheckBlock FAILED
received: block (12681 bytes)
received block da1d459a890702636cabab7aae29119ba9a8a9aa275342ecf3ea0f6928278bda
ERROR: CheckProofOfWork() : nBits below minimum work
ERROR: CheckBlock() : proof of work failed
ERROR: ProcessBlock() : CheckBlock FAILED
received: block (1402 bytes)
received block 32df0aaaec4a2ef37b4a8362f25b175e339db332f13b70e752eecbf5affa3dd1
ERROR: CheckProofOfWork() : nBits below minimum work
ERROR: CheckBlock() : proof of work failed
ERROR: ProcessBlock() : CheckBlock FAILED
received: block (4438 bytes)
received block 824f753966cab50ed248c2e3ce210998bdb00a67501d1ed5cae73c9b9e9ba6f5
ERROR: CheckProofOfWork() : nBits below minimum work
ERROR: CheckBlock() : proof of work failed
ERROR: ProcessBlock() : CheckBlock FAILED
received: block (16460 bytes)
received block 803879d05d90b1eee6c041216febd789f1415ee2181d9abf55f9875d6aad0b8f
ERROR: CheckProofOfWork() : nBits below minimum work
ERROR: CheckBlock() : proof of work failed
ERROR: ProcessBlock() : CheckBlock FAILED
received: block (11741 bytes)
received block 1ee431f32e74a0d2ff61f2556a50fdc44de7947a7585642be87ece528d50b5d2
ERROR: CheckProofOfWork() : nBits below minimum work
ERROR: CheckBlock() : proof of work failed
ERROR: ProcessBlock() : CheckBlock FAILED
received: block (81 bytes)
received block dd8cf762dbd490d0a234796ff5f5fd7cb7f13344ae31b1964b17aa97562879ac
ERROR: CheckBlock() : size limits failed
ERROR: ProcessBlock() : CheckBlock FAILED
received: block (5718 bytes)
received block 507aa2e8f8bcc8c4792f50686f8115396346ede5a021ef9b2cf0699d8547e5b3
ERROR: CheckProofOfWork() : nBits below minimum work
ERROR: CheckBlock() : proof of work failed
ERROR: ProcessBlock() : CheckBlock FAILED
received: block (15832 bytes)
received block f997af18bba58e6f732416e2626aa04d0b06c432e10a1473a12214b2ef5e5bd6
auxpow err 1
ERROR: CheckAuxPowProofOfWork : block does not have our chain ID (got 22888, expected 91, full nVersion 1500000000)
ERROR: CheckBlock() : auxpow proof of work failed
ERROR: ProcessBlock() : CheckBlock FAILED
received: block (8077 bytes)
received block f29045e04deaaebe1047fee54649809769b6f270f88148e2ebc43551b3b551cd
auxpow err 1

liaise with leathan to setup.

For building with Ubuntu 22, gcc-11 (the default) fails. Thus we should instruct users to use gcc version <= 10 for now. Also the windows README shows an incorrect Bitmark version number. Solution: bitmarkcc@df1e617 and bitmarkcc@d58aa6a

Wallet causes the yiimp stratum to segfault if auxPOW is enabled on Lyra2v2.

We have a few little bits of the eco system dotted in various areas

This thread is open to add bits and pieces about the explorers, mining pools, wallets, wiki, source, libraries and other stuff as of 2021

Hopefully I'll be able to make a documentation of this after gathering the links

Just tracking messages of this kind:

Been running a btm server for several days now, I use it to send tx. Normally it works fine, but today I got:

error: {"code":-2,"message":"Safe mode: Warning: The network does not appear to fully agree! Some miners appear to be experiencing issues."}

OS : Ubuntu 20.04
Codebase: https://github.com/dbkeys/bitmark/tree/ssl-only

I guess this is some teething problems with the 20.04 build, good to keep an eye on it and track in this issue

Related issues: #108 #107

Hi,
The new version of Bitmark core V.0.9.7 is getting close while synchronizing the block 451098. What need to be done to fix this issue

Regards
Sureshkumar, K

There are some problems with how openssl is used.

In bignum.h the BIGNUM *bn data member of CBigNum, is referenced by overloading the ampersand (&) operator. This can lead to unpredictable behavior (https://www.appmarq.com/public/changeability,8010,Do-not-overload-the-ampersand-comma-logical-AND-or-logical-OR-operators). Also, util.h does not need to be included.

The usage of ECDSA_SIG_get0 is not ideal... There also needs to be a call to ECDSA_SIG_set0 for openssl versions >= 1.01 when initializing the ECDSA sig (this leads to an error in one of the unit tests).

Solution: bitmarkcc@799f18c

I am convinced that we must have some algorithms returned to native-only status. Currently, since Fork 1 in June of 2018, all 8 Proof-of-Work algorithms are merge-mine enabled.

The advantage of merge-mining is that very large hashpower secures our blockchain throught harnessing hashrate of other coins via the AuxPoW mechanism. (This is particularly true of SHA256 and Scrypt)
The disadvantage is that there is no native mining any longer, and anyone interested in the Bitmark project and in mining bitmark must compete with very large "foreign" hashrate, unrelated to the Bitmark project. There is no focused, Bitmark-only dedicated mining for us now; all the mining is mostly the by-product of miners mining other coins and regarding Bitmark as a mere "small bonus".

Most other, if not all other, coins that allow merge-mining, always reserve some algos as exclusive to their blockchain
I believe we must address this by returning at least 1/3 or perhaps as many as 1/2 of our algorithms to native-only status. This will be a net improvement, with no downsides. This change does not affect neither the emission rate nor the total emission. We have always respected the total cap on emission. Security is rock solid with several algos and several of those with very large hash rates.

It only means that those with an interest in Bitmark for its own sake will have the ability to mine it without having to compete with any foreign, unrelated hashrate; in the native-only algos, they will have to compete only with other Bitmark miners.

We are due to freshen our algos in any case, because as several were chosen because of the hashrate or philosophy (democratic mining) of the coins implementing them and those coins have improved or changed the algos as well, we should keep up to date.

This is the case with Lyra2REv2, which was used by VertCoin. Now, VertCoin has adopted a proof-of-space algo developed by their team, to ensure widespread democratic mining, "VertHash". I believe we should replace Lyra2REv2 with VertHash
CryptoNight has also evolved and we should update it accordingly to harness the hashrate of the popular privacy coin, Monero; the same is true for ZCash's EquiHash.

To achieve at least 1/3 native algos, I recommend:

• Swapping Yescrypt merge-mined for Yespower as a native algo. The developer of both these algos, SolarDesigner, developed Yespower expressly for cyrptocurrency.
• Returning Argon2d to native mining.
• Introducing a 9th algo as native-only: our original algorithm SCrypt. We would then have merge-mined SCrypt, and the same algorithm SCrypt but in a native-only flavor.

I think these algo updates and restoring a measure of native mining are justified and desirable. There are also some minor bugs outstanding that need to be fixed, but require a hard fork. For these reasons, I think that another fork, Fork 2 is warranted and should be undertaken. We have traveled that road, and done it before, succesfully.

from @dbkeys in #103

Getting everyone on the same page. The original emergency fork was a response to the inconsistent mining, firstly, famine and feast, and then large reorgs. Specifically it was unanimously agreed that the fork was a one off

By that reasoning a 2nd fork aka "Fork 2", is a hard NACK by default, unless as a bug fix. So, we should separate out bug fixes from new development. This is not a project with continuous rolling forks, like many other coins, we are simply a stable block chain on which to build our signature use case, namely marking

That said, I think we should stay open minded, and consider proposals on their merits, over time. We should keep up to date with innovation in the space. As before, the bar is extremely high and requires unanimous approval. The proposal should contain a logic and a motivation. Such as to allowing greater decentralization away from large mining pools

I'm opening this issue not to report a bug, but to start a discussion about merged mining in Bitmark, which potentially could be seen as Bitmark improvement proposal.

First I want to say kudos for adding multiple mining algorithms, kudos for new Coin Emission Modulation and for merged mining only half a kudos from me.

Merged mining can be seen as positive because it increases hash power, to prevent blockchain attacks, and on the other hand it is also a weakness because of mining centralization. Good summary about this: https://eprint.iacr.org/2017/791.pdf

Making every algorithm merged mineable, in my opinion, is unnecessary decision, and will eventually lead to mining centralization around small number of large pools.

But the biggest impact merge mining will have on the price. There are already couple of large mining pools that are merged mining some of the Bitmark algorithms. This pools doesn't send their miners Bitmarks. Mined Bitmarks are market sold on the exchanges and a miner receives Bitcoin or some more value coin. You can probably see where this is going to lead.

Also CEM doesn't have much sense with every POW is merged mineable, pool operator doesn't cost anything to produce new blocks, and they probably wont stop mining at any price.

So my biggest question is why every mining algorithm is made merged mineable?

Myriad coin is a good mPOW merged mineable coin example. Myriad coin has 5 POW algorithms, but only two of them are merged mineable - SHA256d and Scrypt. That way they made optimal solution that insures blockchain security, fair mining and coin price.

Some of mine ides how to overcome the above issues:

1. Reduce reward for merged mined block. Something like third of the regular mined block. This would have positive impact on price.
2. Not allow every block to be merged minded. Allow couple of regular blocks before merged block can be solved again.
3. And maybe the best would be have only a couple of merged mineable POW algorithms, and the rest to be regularly mined. Plus reward is reduced for merged blocks.

TLS / SSL Updates

The update for libboost and openssl has been done; branch 'ssl-only' on my github page takes care of that . It was developed as v0.9.7.3. Now that it is stable, I will soon merge it to the official master branch and tag it v0.9.7.4 and make an official release with binaries.

From @dbkeys

I've been testing here: #107

/usr/include/boost/bind/bind.hpp:463:35: error: no match for call to ‘(boost::_mfi::mf3<void, CWalletInterface, const uint256&, const CTransaction&, const CBlock*>) (CWalletInterface*&, std::_Placeholder<1>&, std::_Placeholder<2>&, std::_Placeholder<3>&)’
/usr/include/boost/bind/bind.hpp:319:35: error: no match for call to ‘(boost::_mfi::mf1<void, CWalletInterface, const uint256&>) (CWalletInterface*&, std::_Placeholder<1>&)’
/usr/include/boost/bind/bind.hpp:319:35: error: no match for call to ‘(boost::_mfi::mf1<void, CWalletInterface, const CBlockLocator&>) (CWalletInterface*&, std::_Placeholder<1>&)’
/usr/include/boost/bind/bind.hpp:129:19: error: no match for ‘operator==’ (operand types are ‘const std::_Placeholder<1>’ and ‘const std::_Placeholder<1>’)
/usr/include/boost/bind/bind.hpp:129:19: error: no match for ‘operator==’ (operand types are ‘const std::_Placeholder<2>’ and ‘const std::_Placeholder<2>’)
/usr/include/boost/bind/bind.hpp:129:19: error: no match for ‘operator==’ (operand types are ‘const std::_Placeholder<3>’ and ‘const std::_Placeholder<3>’)

Solution: bitmarkcc@a8d080e

Also this commit retains consistency with boost::placeholders: bitmarkcc@ac2ec68

Hi,

To be consistent with all the other multi-algo coins could you add the missing fields:

pow_algo_id, pow_algo and difficulty

Example from ARG:

ARG scrypt
{
"version": 4140300,
"protocolversion": 1090000,
"walletversion": 60000,
"balance": 9.29367439,
"blocks": 3138494,
"timeoffset": -1,
"connections": 19,
"proxy": "",
"pow_algo_id": 1,
"pow_algo": "Scrypt",
"difficulty": 2637127.305992147,
"difficulty_sha256d": 2629485835.201973,
"difficulty_scrypt": 2637127.305992147,
"difficulty_lyra2re2": 200.2645212118318,
"difficulty_groestl": 5973.255004714738,
"difficulty_argon2d": 0.02092733630310869,
"difficulty_yescrypt": 0.127252427184466,
"testnet": false,
"keypoololdest": 1527772795,
"keypoolsize": 103,
"paytxfee": 0.00000000,
"relayfee": 0.00001000,
"errors": ""
}

The "difficulty": value should always match what the pow_algo is.

With the newer openssl (as in Ubuntu 22) some unit tests fail, so I've implemented Bitcoin's custom library for ECDSA crypto for validating signatures. For new blocks, signatures have to be strictly DER, but for prefork blocks that's not the case, as well as in the unit tests. This library can be useful for other ECDSA crypto operations, but for now we can use it just for the signature validation. Here is the patch: bitmarkcc@e6bdd4b

There are many new files added in the src/secp256k1 dir. You can run a diff and check that they are the same as Bitcoin's (thus safe). The rest of the files changed are configure.ac, src/Makefile.am, src/Makefile.include, src/key.cpp, src/test/Makefile.am.

@eleneeugene your commit breaks the build

https://github.com/project-bitmark/bitmark/blame/0.9.7/src/qt/overviewpage.cpp#L155

compiler says "BitcoinUnits" is not defined, please change it to "BitmarkUnits" everywhere

I tried creating an OP_RETURN tx, but it gave me the error:

bitmark-cli createrawtransaction '[{"txid": "'ccfa3b0015ccb843a0020b840361e79c5c6fdefbc5cbe92bf1ab4a590436a156'", "vout": '0'}]' '{ "'data'": "'4920616d204672616374616c456e6372797074'",  "'bVTq2mjh6qEwZnnV8kRGynDN9z3dXQLJ8w'": '0.0099' }'

error: {"code":-5,"message":"Invalid Bitmark address: data"}

Without the data param, it works:

bitmark-cli createrawtransaction '[{"txid": "'ccfa3b0015ccb843a0020b840361e79c5c6fdefbc5cbe92bf1ab4a590436a156'", "vout": '0'}]' '{ "'bVTq2mjh6qEwZnnV8kRGynDN9z3dXQLJ8w'": '0.0099' }'

010000000156a13604594aabf12be9cbc5fbde6f5c9ce76103840b02a043b8cc15003bfacc0000000000ffffffff01301b0f00000000001976a914b78e79f7cbb5eef366a11accdebeb2d823270f2388ac00000000

Modern distros are on the Berkley DB 5.x series;
workaround: "./configure --with-incompatible-bdb"; This might (will ?) result in generated wallet.dat not being readable by older versions of bitmark.

The currently listed service for getting the external ip is whatismyip.io doesn't seem to be working properly. Thus I recommend switching back to checkip.dyndns.org as patched in this commit: bitmarkcc@714657b

Trying out the latest ubuntu 22.04

installation
    git clone https://github.com/project-bitmark/bitmark.git
    more doc/build-unix.md
    sudo apt install -y autoconf build-essential libtool autotools-dev libssl-dev libsodium-dev libdb++-dev libboost-all-dev pkg-config
    ./autogen.sh
    ./configure --with-incompatible-bdb

Gives the following issue (possibly related to libssl)

tinyformat.h:802:9: note: here
  802 |         case 'g':
      |         ^~~~
make[3]: *** [Makefile:1141: main.o] Error 1
make[3]: Leaving directory '/home/ubuntu/bitmark/src'
make[2]: *** [Makefile:1163: all-recursive] Error 1
make[2]: Leaving directory '/home/ubuntu/bitmark/src'
make[1]: *** [Makefile:786: all] Error 2
make[1]: Leaving directory '/home/ubuntu/bitmark/src'
make: *** [Makefile:518: all-recursive] Error 1

search gives some pointers

I think it would be a good idea to change the private key prefix from what it is now to 'b' + 128.

This will enable us to use lots of tooling without having to reengineer it and/or get patches upstream which can be quite time and work intensive.

I dont think much will break, because the underying private key is still the same independent of the base58 check prefix.

I use the latest source code.

Error in logs

In block explorer - https://chainz.cryptoid.info/btm/
block 518192

Linux cmd -
"version" : 90803,
"protocolversion" : 70004,
"walletversion" : 60000,
"balance" : 43.67411264,
"blocks" : 518192,
"timeoffset" : 0,
"connections" : 33,
"proxy" : "",
"pow_algo_id" : 1,
"pow_algo" : "SHA256D",
"difficulty" : 4550197735.87287235,
"difficulty SCRYPT" : 4565238321.23421860,
"difficulty SHA256D" : 4550197735.87287235,
"difficulty YESCRYPT" : 395775.61542701,
"difficulty ARGON2" : 57671.75850463,
"difficulty X17" : 27722770.85589155,
"difficulty LYRA2REv2" : 375112875.74920577,
"difficulty EQUIHASH" : 390742.84964733,
"difficulty CRYPTONIGHT" : 32616.68046951,
"moneysupply" : 9615144.54067053,
"testnet" : false,
"keypoololdest" : 1536164182,
"keypoolsize" : 101,
"paytxfee" : 0.00000000,
"relayfee" : 0.00001000,
"errors" : ""

I updated the sources, removed the blocks and again the same thing.

Hi,

I'm trying to change the default algo but seems using

miningalgo=X17

in .conf doesn't take

and commandline

bitmarkd -miningalgo=X17

Doesn't either....

This change does not affect neither the emission rate nor the total emission

Further to this comment here from @dbkeys and follow up:

#103 (comment)

How do we verify the emission schedule for those that have followed the coin a while. I do get asked this and sympathetic people say to me 'they changed the emission'

What can I point them to that will verify that the community designed halvings and emission have been retained

If it's a case of having to read the code, the bar is going to be too high for most people

bitmark-cli getmininginfo
{
"blocks" : 451365,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"reward_next" : 15.00000000,
"reward_max" : 15.00000000,
"hashrate_4max_reward" : 35000000000,
"difficulty" : 31.24732609,
"errors" : "",
"genproclimit" : -1,
"networkhashps" : 40838757117513.62500000,
"pooledtx" : 0,
"testnet" : false,
"generate" : false,
"algo" : 0,
"algoname" : "SCRYPT",
"hashespersec" : 0
}

bitmark-cli getinfo
{
"version" : 90700,
"protocolversion" : 70002,
"walletversion" : 60000,
"balance" : 0.00016242,
"blocks" : 451365,
"timeoffset" : 0,
"connections" : 18,
"proxy" : "",
"difficulty SCRYPT" : 204207957.39825028,
"difficulty SHA256D" : 1.00000000,
"difficulty YESCRYPT" : 96.10301716,
"difficulty ARGON2" : 277.43863202,
"difficulty X17" : 475146.84641310,
"difficulty LYRA2REv2" : 1590063.61880842,
"difficulty EQUIHASH" : 21.33334915,
"difficulty CRYPTONIGHT" : 31.24732609,
"moneysupply" : 8740490.00000000,
"testnet" : false,
"keypoololdest" : 1509137009,
"keypoolsize" : 101,
"paytxfee" : 0.00000000,
"relayfee" : 0.00001000,
"errors" : ""
}

Seems the difficulty in getmininginfo just randomly picks a diff to display rather than the diff that the wallet is set for, which is scrypt.

Hi, dear dev!

Some time linux wallet(compiled from yesterday's master clone) shows that error.

If I will restart daemon - I will get corrupt block and have remove blockchain database and resync from the network and some of mined transactions will be discarded.

Have you idea how to fix the problem?
It seems to exchange will not work with buggy wallet.

Thank you.

I am not prog, but I am good linuxoid. I cam help you with debugging/logs,etc...

http://prntscr.com/k2vg5e

thank you.

Ubuntu 22 uses gcc-11 as default, and this causes compilation and runtime errors.

In a previous issue I mentioned to notify users that we don't support gcc-11, but now I have a possible solution:

First is to update blake: bitmarkcc@cb67862
The code for this comes from here: https://github.com/BLAKE2/BLAKE2/tree/20190724/ref

Next, we need to fix Lyra2REv2 because with the current code the gcc-11 compiler produces a runtime error (incorrect hash) for this algorithm and thus nodes can't sync. I dealt with this before with a sort of hack in my lm branch: bitmarkcc@cb67862 (see the changes to src/bmw.c). But I think a better solution is to use a different implementation of the BMW hash, at least for lyra2. x17 uses the 512 bit BMW hash and it works fine, so we can leave that as is. The implementation of BMW I found is here: https://github.com/floodyberry/supercop/tree/master/crypto_hash/bmw256/ref and it looks like a reputable repository. The patch that uses this for Bitmark is here: bitmarkcc@f6faae9

Had a chat with @dbkeys yesterday

I think we're at a consensus that the block chain we have is ready to use, and that we want to start to fill the blocks with marking related activities

Adding marking to blocks is a win-win because the we believe the value of the project is the sum total of everything that is marked. Our successful pilot to poloniex to 1000s of users shows there is appetite for this. We need to get back to that

This also creates a permissionless development environment where many developers and communities can work independently and bitmark becomes a glue between them. The idea of "let 100 flowers bloom"

This marking on the original chain constitutes the first work stream, which has always been the aim of the project

There is a second work stream regarding on-chain changes. This is more intensive and impacts everyone in the community. While not wishing to shut this work stream down, it should to happen in a more controlled way, as we've been in emergency mode for the past years, due to our small volunteer based team, and we now have a chance to come out of it. That inevitably means doing things more carefully, and more slowly than we have

I suggest over time moving to shore up the development practices. Perhaps over the next year or so

• Merges to master require review (which can be added to the github flow)
• All proposed merges, including minor ones, must have an issue associated with it
• Improvement proposals (inc. soft and hard forks) must have a BIP associated with it
• BIPs must have a motivation section, which is the first port of call for discussion
• At some point we should turn on 2FA to github

A lot of time, care, and effort was put into the fork, to decrease the centralization associated with the selfish mining farm. I think we can now start to focus on using it, and start filling up the blocks

I am unable to compile the source under any Debian amd64 version (tried 8 and 9).

On Debian 9 it seems impossible due to too new openssl version with errors like:

...
bignum.h: In function 'bool operator>(const CBigNum&, const CBigNum&)':
bignum.h:594:83: error: cannot convert 'const CBigNum*' to 'const BIGNUM* {aka const bignum_st*}' for argument ' ' to 'int BN_cmp(const BIGNUM*, const BIGNUM*)'
inline bool operator>(const CBigNum& a, const CBigNum& b) { return (BN_cmp(&a, &b) > 0); }
...

On Debian 8 I can overcome some c11 related errors with:

./autogen.sh && ./configure --with-incompatible-bdb --without-miniupnpc && CXXFLAGS="-std=c++11" make

But then I am stuck with the following compile errors:

In file included from cryptonight/crypto/hash.c:35:0:
cryptonight/crypto/hash-ops.h:65:15: error: expected declaration specifiers or '...' before 'sizeof'
static_assert(sizeof(union hash_state) == 200, "Invalid structure size");
^
cryptonight/crypto/hash-ops.h:65:48: error: expected declaration specifiers or '...' before string constant
static_assert(sizeof(union hash_state) == 200, "Invalid structure size");
^
Makefile:1047: recipe for target 'cryptonight/crypto/hash.o' failed
make[3]: *** [cryptonight/crypto/hash.o] Error 1

I believe we are around the next epoch, about now

I've been monitoring the emission (but not the charts)

It seems there is inconsistent emission, but it's unclear why?

Sometimes 6, sometimes 3, sometimes 4 or 5

@dbkeys @piratelinux any idea what's going on, or what it's supposed to be doing?

Guess is that it's related to the Coin Emission Module ... but I didnt find a way to verify that (yet)

Screenshot below

https://chainz.cryptoid.info/marks/

Im wondering how to run the unit tests

I read the command was make check but when I run it I get:

cd .. && make  am--refresh
make[1]: Entering directory '/home/bitmark/bitmark'
make[1]: *** No rule to make target 'am--refresh'.  Stop.
make[1]: Leaving directory '/home/bitmark/bitmark'
make: *** [Makefile:819: ../aclocal.m4] Error 2

Some of the rpc commands do not behave as expected.

In rpcblockchain.cpp:
The GetDifficulty method uses the tip's difficulty instead of the height specified (when passing next=true). The GetPeakHashrate and GetCurrentHashrate methods should convert the bignum to a uint256 instead of a ulong in order to allow for larger hashrates. GetAverageBlockSpacing should use MedianTimePast to be more reliable. The block variant info is not needed (block variant codes were made to allow for the signalling of multiple forks using the same version number).

In rpcclient.cpp:
Set generate returns a segmentation fault without a 3rd parameter. getblockreward can be made more useful by allowing a noScale parameter, to show the block reward without the CEM scaling.

In rpcmisc.cpp:
getblockspacing, getblockreward, and getdifficulty can be made more efficient by directly passing the height index to chainActive instead of walking back the blockindex to the needed height. The chaindynamics "sdifficulty" (unweighted difficulty) is passing NULL to the blockindex parameter. It should pass the blockindex corresponding to the requested height.

Solution: bitmarkcc@3719ed4 and bitmarkcc@ce4b6cd

Project health check

As we will soon enter our 8th year, this is a quick health check to call to see who's around to help reboot the development process for this project

It's been a challenging year all round, for many external reasons, and the project has been largely on auto pilot

Good news is that behind the scenes there's been some great work from @dbkeys on maintaining the website, the BTT thread, explorers, plots, mining, exchanges, block chain dev, and other things

Our software clients still work on windows, macos, and ubuntu 16.04 (I just checked). Ubuntu 20.04 will need some updated instructions due to the upgrades of libboost and openssl

We are still trading on freiexchange, and bisq. More than one explorer works, and the plots from the fork can be examined. The blocks seem to be coming in regularly without reported issues, so we have largely achieved our main goal of having a stable block chain

However, there has been a lack of activity and understandably our price has suffered with many thinking the project is abandoned. So this is a call to see who's interested in rebooting the development effort

What's left to do

There is a bit of maintenance work to explain the history of the project better, why certain choices were made, and what they do. And also to explain how we are different from most alts in being a provably fair coin, with a probably fair emission schedule. ie no ICO, no premine, no instamine, not dev tax, no proof of stake etc.

The eco system needs documentation to show where all the different pieces are

The instructions for building need to be updated so that we can more easily run and build on linux

Our code base is behind upstream bitcoin by some years. So we might need to import some of the fixes there, which is a big task in itself. Some of the newer optimizations we dont need just yet, as our blocks are not full

The idea of grounding reputation trees in the block chain needs to be fleshed out and documented. There was some talk about OP_RETURN and OP_COMMENT, but I think we are actually able to do this today with a modified chainpoint and single use seals, and so, not requiring any low level changes. I've been doing some experimental work on this, and it's gone very well. Happy to share findings on this soon, and write up

There's been some talk about having 1 of our 8 algorithms as a special bitmark algo that can be CPU mined, to generate interest in decentralized mining. This might be an avenue to explore, provided that the proposal is clearly documented, reviewed, and our code base is in a good and well maintained state

We are also I think close to the point where the first reputation trees can start to be grounded in our block chain. I may have this working quite soon. Again, this requires a bit of documentation

Call for participation

We continue to work, as we have from the start, as a 100% volunteer based team, on a best effort basis. That means that things can be slow, but we are a community designed coin, which will have an emission period over many years to ensure fairness. Whether or not that model will work in the long-term, time will tell!

If any devs (new or old) wish to help out with the project and the vision of marking, please feel free to drop a note here. Or visit us on slack. Or you can mail me a ([email protected])

Thanks!

Just a call to see if we can find some mutual time free to go over the open issues and way forward

And what's the best place to discuss, e.g. slack or some other venue

There's no real urgency with this, I appreciate we are a volunteer base, and there's lots going on in the outside world right now, so people may be quite busy

But let's see if we can get some momentum and productive discussion going some time soon (ie in Q2)

Feel free to reply here (or on slack) or email me ([email protected]) ... ill reply here to anyone that reaches out ...

New Machine

./configure 
./configure --with-incompatible-bdb
./configure --without-bdb

Tried these three and it gives the error

checking for Berkeley DB C++ headers... no
configure: error: libdb_cxx headers missing

Seeing if I can figure this out

Older machine

It does actually compile and bitcoind + bitcoin-cli make (but not bitcoin-qt for some reason)

Issue here is that it stalls at:

"blocks" : 119808,

Been there for about an hour. Other commands are working tho

Good progress on libssl and libboost, I'll keep seeing if I can figure out the issues

@akrmn2021 wrote:

But first note that OP_PUSHCODE is my own invention, so that's why you never heard of it. And yes I think this is needed for the next layer of functioning, i.e. creating a reputation system instead of a vanilla chain, though it can even be used to create a highly secure vanilla chain.

This issue is for discussion around OP_PUSHCODE

Current Release v0.9.7.2 fails to Install on Apple Macs. Installation fails with an "Not enough File Descriptors" message.
However, even instruction the OS to assign more file descriptors does not resolve the issue.

Wasnt sure where to find the minimum fee, or if there is one

I've seen both 0 and 0.0001 MARKS in the explorer

https://chainz.cryptoid.info/marks/tx.dws?1921288.htm

https://chainz.cryptoid.info/marks/block.dws?1150676.htm