Author Topic: FST - security Vs "weight" -- that is, how make the FST client loose some pounds  (Read 247 times)

0 Members and 1 Guest are viewing this topic.

Offline fastcoinrules

  • Newbie
  • *
  • Posts: 35
  • Karma: +4/-0
  • Newcomer
    • View Profile
Interesting discussion from the btctalk forum.
At due time, I think the DevTeam should evaluate if this thing needs to be addressed.
Almightyruler said:

"....FST is a real resource hog. On my server the FST client consumes a whopping 3.7GB of RAM, which is by far the most of any of the clients I run. For comparison, the Bitcoin client only uses 0.6GB (although, to be fair, BTC does use much, much more disk space)

Because of the huge number of blocks a sync or rescan can take several days, at high CPU load.

I surveyed the last 500 blocks in the FST blockchain and over 96% have no additional transaction beyond the miner reward. The tradeoff for fast transactions is that the blockchain continues to grow to excess, with mostly empty blocks being issued every 12 seconds.

Some coins have toyed with limiting the block creation rate (and therefore blockchain bloat) by only permitting new blocks when a certain time period has elapsed, or there are a certain number of transactions in the mempool. So you could have a default block period of 1 or 2 minutes, EXCEPT when there's a transaction that's moving through, which will cause a more rapid block creation rate. This would greatly increase the average transaction density of each block...."


-----
(Me) While I see my own "Hog" is eating 2,1GB of Ram (down from the 3.6GB above), yes, I think here the software experts could really run a contest to find out... Who has the longest.... ;D ;D
This is not needed here and now, but all must be addressed if you think to a long term scenario.
There are 3-4 very experts guys.... Almighty, Vampirus, Stouse and others who could make the difference, just by looking at how much interest they're putting into the discussion.



Offline FSTFan

  • Newbie
  • *
  • Posts: 11
  • Karma: +4/-0
    • View Profile
Interesting discussion from the btctalk forum.
At due time, I think the DevTeam should evaluate if this thing needs to be addressed.
Almightyruler said:

"....FST is a real resource hog. On my server the FST client consumes a whopping 3.7GB of RAM, which is by far the most of any of the clients I run. For comparison, the Bitcoin client only uses 0.6GB (although, to be fair, BTC does use much, much more disk space)

Because of the huge number of blocks a sync or rescan can take several days, at high CPU load.

I surveyed the last 500 blocks in the FST blockchain and over 96% have no additional transaction beyond the miner reward. The tradeoff for fast transactions is that the blockchain continues to grow to excess, with mostly empty blocks being issued every 12 seconds.

Some coins have toyed with limiting the block creation rate (and therefore blockchain bloat) by only permitting new blocks when a certain time period has elapsed, or there are a certain number of transactions in the mempool. So you could have a default block period of 1 or 2 minutes, EXCEPT when there's a transaction that's moving through, which will cause a more rapid block creation rate. This would greatly increase the average transaction density of each block...."


-----
(Me) While I see my own "Hog" is eating 2,1GB of Ram (down from the 3.6GB above), yes, I think here the software experts could really run a contest to find out... Who has the longest.... ;D ;D
This is not needed here and now, but all must be addressed if you think to a long term scenario.
There are 3-4 very experts guys.... Almighty, Vampirus, Stouse and others who could make the difference, just by looking at how much interest they're putting into the discussion.
In terms of FastCoin Wallet or (Client) being a "resource hog" when compared to Bitcoin a few additional items need to be considered if you are to have an apples to apples discussion on this matter and not oranges to apples.  It would appear that the FastCoin Wallet or (Client) would indeed consume additional PC resources then the BitCoin client and this largely has to do with the fact that it has a much larger/deeper BlockChain to manage than Bitcoin's.  However although the PC resources are more demanding, this is not necessarily a bad thing. We would like to reference a post explained by Bitcointalk Forum member and FastCoin lead dev “fast-coin” in his July 9th Bitcointalk.org post here…

https://bitcointalk.org/index.php?topic=218852.1580

“Thanks for your question Xapwxrm5732,

We do not believe this to be the case for several reasons.  One way of describing why could be paralleled with Moore's Law...

https://en.wikipedia.org/wiki/Moore%27s_law

If you have not heard or read about Moore's Law basically it describes the phenomena of computing power doubling every 12 - 18 months.

Cyrptocurrencies in general are also very dependant on the Internet's Networking infrastructure in order to be functional.  Over 4 years ago when FastCoin was originally developed, the average "Broadband" internet speeds were in the 1 - 5Mbps range in North America.  The developing and other countries around the world generally are a few years behind North America with respects to Network Internet Infrastructure with a few exceptions, it would be safe to say that some countries still had dial-up or up to 1Mbps Broadband speeds at that time and still do today.

Today, at least in North America, we are witnessing speeds of up to 1000Mbps or 1Gps Broadbands...

IE Google Fiber https://fiber.google.com/about/

 and Developing and other Countries around the world are quickly running at 25Mbps or higher.

With the increase made in computing power, and storage capacity on PC's continuing to fall in price per MB, coupled with the network Internet Broadband speeds growth in development in terms of greater reach and speed capacities, FastCoin Blockchain size will become a mute point and the speed in which it reads or processes will also become muted.

The great thing is that the FastCoin Developers at that time, (4 years ago) pushed the absolute limits of block chain speeds on existing PC's and computing infrastructure.  Today with the advancements made in computing, only helps, not hurts FastCoin's present and future processing of transactions.

Hope this helps answer you question.

Best Regards

Fast”


Some Bitcoin users would refer to this as "Blockchain Bloat"

Blockchain Bloat is a term that is generally used by Bitcoin enthusiasts who are emotionally attached to Bitcoin.  FastCoin was designed over 4 years ago and many technological advancements in internet network broadband speeds and PC’s hard drive and RAM capacity have evolved significantly since then and will continue to do so.  Why is this important to state?

Computational power does not exists in a vacuum, PC Hardware and Internet broadband speeds are constantly evolving and the case of “BlockChain Bloat” that was floated around by Bitcoin enthusiast over 4 years ago, does not hold any water today, and will certainly be a non-issue moving forward.

With respects to FST BlockChain rescan o resync, if the wallet has been offline for about 1 to 2 weeks, from our experience the synchronization does not take days to catch up, rather a few minutes.  It also depends on the internet speed of the user in question as well as the total number of peers the FastCoin wallet reaches while it is trying to perform its synchronization process.  Directly connected hardwired connection tend to be more reliable than Wifi connections.

Finally with respects to "Block creation rate" settings, these variables again depend upon how many given transactions are being broadcast to the network at any given time and how many peers are actively participating in processing that transaction.  Our experience has show no significant issues with the wallet 10.2.2 performing these transactions, if users are experiencing issues of this nature, it would be recommended that they upgrade to the wallet 10.2.2 ASAP.  Again if some larger transactions are not being process correctly, this is a rare event, and the CORE Dev team will need additional information to validate this phenomena and under what conditions this particular situation arises.

Truly

FSTFan