On our internal tests the HEAT JVM has been capable of achieving an unbelievable rate of several millions of updates per second on commonly available 16-core server.
This is wrong actually.  It should say "on my old and rusty 4-core linux desktop - with plain spinning disks". On a 16-core server with SSD drives its more likely to see 30 to 40 million updates per second. |
|
|
|
I will be following this, gl with the project!
Dank u  |
|
|
|
I like your site! Signed up for the newsletter. I'm sure Svante will contact you. |
|
|
|
This is something interesting to follow.
Happy to hear that  |
|
|
|
What number of FIM are out in the World as of now?
There is a live ticker on CMC. http://coinmarketcap.com/currencies/fimkrypto/Total supply includes the amount of FIMK reserved for basic income payments to members. Available supply is the number of FIMK out there. |
|
|
|
POS and POP... what is POP?
P.O.P. stands for Proof of Presence. Where Presence refers to the presence of one specific blocks file. A blocks file in turn is a list of blocks and within those blocks are transactions, this is all binary data, all in one stream which allows for blazing fast blockchain scans (scanning a blocksfile of 1 GB takes around 2 seconds or less). A specific size for each blocks file is hard to give but they will be roughly 1 GB in size and will contain approx 5 million transactions per blocks file. For the consensus mechanism to function properly you only need the latest blocks file, so whether the HEAT blockchain is 1 GB or 9.000 TB you always only need the last blocks file. To achieve this, and many other things, in HEAT we have pulled apart storage of balances and storage of transactions, to be able to validate the latest blocks file nodes do need all the balance files for each previous blocksfile. But this will not be a problem since balances take up much less space, you could store 100.000 balances in a file that is less than 2 MB. ---- But lets get back to POP, this is an incentive we have build into the protocol where we reward node operators to host past blocks files. The proof comes from a challenge that is written to the blockchain and which you can only solve by scanning the entire blocksfile from start to finish, those node operators then publish their proof to the blockchain and the protocol will reward them if correct. To be clear.. POP has no meaning for the consensus mechanism, for consensus we use plain POS. |
|
|
|
You could start by putting your idea to a document, take a cryptographic hash of that document and put that on a/the blockchain. If you publish that hash somewhere public you'd at least have proof that you came up with it first. [they do that here https://www.proofofexistence.com/] One could never be sure an idea is not stolen apart from not sharing the idea in the first place. For all the other cases I guess you should build at least some trust with the developer, no way around that. |
|
|
|
|
I'll be happy to answer any technology related questions regarding the new project.
|
|
|
|
Any thoughts on nxt 2.0? Aka. Will fimk take a similar scalability approach?
Yes I have some thoughts about 2.0. https://nxtforum.org/core-development-discussion/nxt-2-0-design/msg210552/#msg210552https://nxtforum.org/core-development-discussion/nxt-2-0-design/msg210562/#msg210562https://nxtforum.org/core-development-discussion/nxt-2-0-design/msg210588/#msg210588TL;DR It's very unlikely we will go the same route as NXT has gone with the 2.0 design. We believe to tackle the scalability issue you first have to move the so called "derived data" away from the core FIMK database (the same one holding the blocks and transactions) and into a database optimized for serving big numbers of users. Right now we do that with MySQL but our replicator setup could just as easily work with larger databases since it's much like a plugin. Then for anyone hosting a site that uses FIMK in whatever way the setup is to install the FIMK background process (which talks to the p2p network) and tell the FIMK background process to what external database it has to replicate the data now stored in the FIMK database. This way we can remove the biggest part of all the various tables and indexes in the FIMK database and even stop creating new Attachment types (which require hardforks to implement) since they will exist outside the blockchain and only have meaning in the replicated database. All of this fits nicely with our recently shifted focus towards a bigger end to end setup which consists of: - a client framework (we have rewritten lompsa in Typescript and Angular 2 for this - this is mostly done) - a server framework (this part is under heavy development and uses Scala and Play framework, this is both enterprise friendly and can run under heavy server load) - a replicator framework (there is a functioning prototype on github right now which creates a one to one replication of various blockchain data to an external MySQL database) |
|
|
|
Just an update on my situation: I did get a couple emails from Ronny Boesing, CEO of CCEDK. He said that he will work on trouble shooting the issue with Fimk transactions on Monday. I'm guessing based on what's said here that it's a matter of updating the CCEDK wallets, and that once that happens all deposits made to CCEDK wallets should show up. I'm not sure about withdrawals, though, if they were done on a fork, what happens to those. Hopefully by Tuesday everything there will be running smoothly.
If withdrawals were sent on a fork, then the person waiting for them, never got them, or were also on the fork. Once they are on the correct chain they will have the coins back and can re-send them correctly. This is correct. Coins would not be lost. If CCEDK sends FIMK to wiser while on the fork, then only according to that fork did wiser receive that FIMK. As soon as CCEDK switches to the master fork they will see the FIMK they send on the bad fork to wiser actually never got send on the master fork and they will appear again in the CCEDK account. The only real real risk of forks is when you sell something for FIMK, you then see the FIMK appear in your account, then you hand over whatever you wanted to sell and when the buyer has disappeared you'll notice his payment was never actually performed on the master fork. |
|
|
|
Users running 0.6.3 or later can update their FIMK installation through the update script. To update to this latest release run this command in your installation folder. sh update_fimk.sh 0.6.4 e02ba501fd1c321fcf4e5cda8274618beb1833366aaecc00d5bea06855a214b4 Thats it. -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
███████╗██╗███╗ ███╗██╗ ██╗ Date : 2016-02-11
██╔════╝██║████╗ ████║██║ ██╔╝ Release : 0.6.4
█████╗ ██║██╔████╔██║█████╔╝
██╔══╝ ██║██║╚██╔╝██║██╔═██╗ http://fimk.fi
██║ ██║██║ ╚═╝ ██║██║ ██╗ https://github.com/fimkrypto/fimk
╚═╝ ╚═╝╚═╝ ╚═╝╚═╝ ╚═╝ https://lompsa.com [online wallet]
Fixes a bug where fresh blockchain downloads could not verify one or more
block generation signatures.
Fixes a bug where pre-private-asset-fork asset issuance transactions where
incorrectly read while uploading blocks to blockchain downloaders.
Introduces some new and extends some existing HTTP API's for use in new
Lompsa client 2.0. These API's are likely to change in the future.
- - getTransactionCount
- - getAccountTransactionCount
- - getBlockchainTransactions
Introduces new websocket push event mechanism for use in Lompsa 2.0, through
this new mechanism clients can register/unregister for detailed server side
push events. Lompsa 2.0 new codebase and extension mechanism are tightly
coupled with this event mechanism.
Adds column sort functionality to getNamespacedAlias API, this is also available
in the bundled client.
Includes a fix for incorrect namespaced alias handling, this fix requires a
hard fork of the network which will be enabled through the setting of another
hard fork alias (this functionality was introduced a few releases ago).
Before we enable the hard fork we would like to see a considerable amount of
nodes to have updated.
~~~ DOWNLOAD ~~~
https://github.com/fimkrypto/fimk/releases/download/v0.6.4/fim-0.6.4.zip
SHA256 e02ba501fd1c321fcf4e5cda8274618beb1833366aaecc00d5bea06855a214b4
MD5 9ec0a3ec5b5fcf5cd2567f010adcde8c
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJWvKi1AAoJEH6Hp7CsNOLVbHcH/jl+gybWhKVzVyHBSzG9HCef
UnwroO1sajfejzsZMW3HPy9mQOBrj0f3gOwegL+c3HLfAXq9sumPnXs6yFylSqR5
BJzTaUc2cZz9ZY/d6bwkjkXFj64+x7D4p31ofnjBriH5pG007EefLz9InoOoE0Td
b62poIV12RK+aAddpUuwDl/fvBrrkHZ2e7cvUP85v5/2A16Qi/ziXTA8CJLUg3wS
r6a989MTXtq7rWsr1sowkWO0w1A6HzmVEAmleN5Wh9/EZLr6Zv6badr1SNKzruHL
wfAaZd9dQr3TmPUZZetlnDQ/X+y0ychKICu7CHKS5AgliQFjP2g+IIqH+QHg+Sk=
=MyJu
-----END PGP SIGNATURE----- |
|
|
|
Easy update to 0.6.3 ...On linux (from the same folder that contains run.sh): curl -L -k -o update_fimk.sh https://git.io/vzhl9
sh update_fimk.sh 0.6.3 2093ef1dbd1e112d85fd6eb96603244400658d6d7ce165184d57faf19a6436b0Thats it.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
███████╗██╗███╗ ███╗██╗ ██╗ Date : 2016-01-30
██╔════╝██║████╗ ████║██║ ██╔╝ Release : 0.6.3
█████╗ ██║██╔████╔██║█████╔╝
██╔══╝ ██║██║╚██╔╝██║██╔═██╗ http://fimk.fi
██║ ██║██║ ╚═╝ ██║██║ ██╗ https://github.com/fimkrypto/fimk
╚═╝ ╚═╝╚═╝ ╚═╝╚═╝ ╚═╝ https://lompsa.com [online wallet]
Bug fix. Accounts that contain ask or bid orders from before the most recent
fork did not return correct results from getActivity API, this resulted in empty
activity lists in the client.
For users who do not access the getActivity API (either directly or through the
client) this update is not strictly necessary.
~~~ UPDATE ~~~
The instruction displayed in the logs to update will be something like this:
sh update_fimk.sh 0.6.3 [insert 64 character sha hash here]
To get around the missing update_fimk.sh file you instead must issue the
following extra command to update to this version, in future versions this extra
step is not needed since the build system now includes that script.
So to update to this release instead do this:
curl -L -k -o update_fimk.sh https://git.io/vzhl9
sh update_fimk.sh 0.6.3 [insert 64 character sha hash here]
If you would first like to inspect the shell script before executing it simply
open https://git.io/vzhl9 in your browser.
~~~ DOWNLOAD ~~~
https://github.com/fimkrypto/fimk/releases/download/v0.6.3/fim-0.6.3.zip
SHA256 2093ef1dbd1e112d85fd6eb96603244400658d6d7ce165184d57faf19a6436b0
MD5 7eee48f34f13614609ce60b27aa5ce45
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBAgAGBQJWrL3qAAoJEP9gzPcARnvnkVsH/isHinJnGZw5ZQ7ZLdyP0TCK
hj9uTDDzzc9BsPMJLVXQcJlQaQAVkQtkJXRS3YQRoGaYZCRwWBa1UuX8Syv0Bubv
l7HxrXmXSLwKk+mnkEqQCtRQKWJXd/CSsihLVX4xKDJjTwTv2XkVCDr41d9DcRE2
UvHYDEKSi86MSvAyVuslAgJ9pZyGA29py4RGoMmrVyta9X7a5jjN7T5Pd6q4aooU
JpK0mdk3Rw/2cxtCCDopETd4hUCEudgxknuqkDoTVI80Uh20IRqD8x4KOOu4bK9v
xt81/oM+6tp4hvbPJOuMT6LjMADobhPl5qeE1YqYZr+OKbUbroHju/YhGXYB3io=
=Y8Tv
-----END PGP SIGNATURE-----
|
|
|
|
The SRWP asset hasn't paid a dividend in close to three weeks. Is everything OK in that quarter?
I dont know about that, but I have seen funbug online during that time, so at least he should be ok. I've notified funbug on forum.fimk.fi that he should upgrade since he was on 0.4.2. He most likely missed that PM. The main SRWP ( funbug) account did not forge any blocks during these past 9 days, which is to be expected when you are not on the 0.6.* fork. For anyone who hasn't done so... Update to 0.6.2! Updating will trim your blockchain up to the hardfork block so you are ensured you will land on the 0.6.* (main) fork. 0.6.2 has an update mechanism to help you update to newer versions. We are working on releasing desktop versions (lompsa) that contain 0.6.2. |
|
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
███████╗██╗███╗ ███╗██╗ ██╗ Date : 2016-01-28
██╔════╝██║████╗ ████║██║ ██╔╝ Release : 0.6.2
█████╗ ██║██╔████╔██║█████╔╝
██╔══╝ ██║██║╚██╔╝██║██╔═██╗ http://fimk.fi
██║ ██║██║ ╚═╝ ██║██║ ██╗ https://github.com/fimkrypto/fimk
╚═╝ ╚═╝╚═╝ ╚═╝╚═╝ ╚═╝ https://lompsa.com [online wallet]
Bug fix for fork issue shown in console as 'java.nio.BufferUnderflowException'.
The bug (fixed in this release) caused an error during blockchain scanning
or downloading.
To prevent peers from being on or switching to a possible fork caused by 0.6.0.
On startup we'll one time delete all blocks after PRIVATE_ASSETS_BLOCK and
force a rescan.
This version blacklists all nodes on or below 0.6.0.
This release comes with a mechanism that allows the FIMK developers to notify
users of updates. The update notifications come with a simple instruction
to upgrade your current version.
We've also added a HardFork module which allows for saver and faster
hardforks, fork heights are no longer hard coded in the java source but (much
more flexibly) written on the blockchain instead.
Special care was given to make sure these variable hard fork heights can only
be set a single time (since you can change alias values).
With these two mechanisms we believe we can now go and release updates at a much
faster pace and much more convenient for FIMK server operators. Without the risk
of forking the network without users noticing.
IMPORTANT INFORMATION ABOUT VERSION MANAGER ...
The version manager reads application version data from the blockchain.
Peers who chose to do so can have their FIMK software periodically check the
blockchain and be notified when their current version is out of date.
There are three values on the blockchain that are involved in this process.
LATEST VERSION (LATESTVERSION/9266582752086146948)
This alias holds the most recent available version and a SHA256 checksum
of the downloadable package.
The version notifcations use this version and checksum to generate a
command you should run to update your current version to LATESTVERSION.
The expected format for this alias:
[0-9]+\.[0-9]+\.[0-9]+(-.+)?\s+[a-z0-9]{64}
MINIMUM VERSION WARN (MINVERSIONWARN/17359617168004080578)
This alias holds the version number and blockheight, only after the
blockheight has passed will the version manager act upon this.
The version number is the minimal version you should run before we start
issuing notifications that your version can be updated.
You can disable this functionality in your nxt.properties config file.
Set `nxt.warnNotLatestVersion=false` to disable this functionality.
The expected format for this alias:
[0-9]+\.[0-9]+\.[0-9]+(-.+)?\s+[0-9]+
MINIMUM VERSION BLACKLIST (MINVERSIONBLACKLIST/9364249966090852339)
This alias holds the version number and blockheight, only after the
blockheight has passed will the version manager act upon this.
The version number is the minimal version you should run before we issue
a notification that your version must be updated.
When the version manager detects you run a version up or below this
version your server WILL BE SHUTDOWN. To start the server again either
update (recommended) or disable this feature in nxt.properties.
Peers who enable this feature will start to blacklist all nodes on the
network that are running a version on or below this version.
You can disable this functionality in your nxt.properties config file.
Set `nxt.shutdownWhenOutdated=false` to disable this functionality.
The expected format for this alias:
[0-9]+\.[0-9]+\.[0-9]+(-.+)?\s+[0-9]+
As mentioned the default behavior for clients who do not disable this feature
is for their servers to SHUTDOWN when we detect the server version is up or
below MINVERSIONBLACKLIST.
The rational behind this is to protect users from accidentally landing on a
network fork because of a required update they've missed.
Running an unsupported version is dangerous and should be avoided for several
reasons:
1. Forgers running an unsupported version will loose their FIMK forged
on that fork. Electricity is wasted running your server and damage is
caused to the rest of the network when you send blocks or transactions
that are incompatible.
2. Exchange operators running an unsupported version run the risk of
loosing money when on a fork. The exchange software will accept
FIMK deposits and credit BTC or other internal tokens to the depositor
if these deposits where made while on a fork the exchange will loose
the deposited FIMK.
3. Merchants very similar to exchange operators risk the loss of funds
when they accept FIMK payments while their server is on a fork.
4. Ordinary users who accept payments or asset transfers risk loosing
those funds since they are on a fork.
~~~ DOWNLOAD ~~~
https://github.com/fimkrypto/fimk/releases/download/v0.6.2/fim-0.6.2.zip
SHA256 75fa306b987fd87f3b7900bc26df379f54e43e05e22a378b94bc83b0b7f1a6db
MD5 3a0dd7dd1934f77fa54ece46d34db137
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBAgAGBQJWqoVWAAoJEP9gzPcARnvnohMH/i1NnSdobvU3NmSM1zeIPDK0
ZEMKWizBWqv4gd34qgPSz+xkYQ5TNGFSseFux7MrTczbtOEQ3XECX/zCGm5paNnB
jXUd/MNqPB5txvsq0mTsxLPscpzb+bnKkfP01KZYyZQsUBRSYtm08CC165N/UFcw
DtecFZ0X7SP5hqHclUyKFwlsFZF0RIUa8nCy8XuLGjriqH+Z/20IYeIc2XLSuLdV
tXISnO+YK/n+AscMRV6HS+wg8vY2ry/LAJeurngVndRjrZTySX0/pStx9P5cHR0w
J9ZtJD0JXhIrJcPbBqCT9pSdsIR0nvOvpMBzQFZTsNcLR4GxmxIYddKeagDefR0=
=k4x8
-----END PGP SIGNATURE-----
|
|
|
|
|
Show Posts
