day 3
still having big problems with my withdrawal
I tried with a 3.5 m amount of PLE, still the error is coming
Anyone knows please what is the maximum amount of PLE that can be sent out from STEX?
Topic: [ANN] [CN-Lite V1] Plenteum - faster, lighter chain, saving on fees (Read 26723 times)
March 28, 2020, 06:07:36 AM
March 25, 2020, 09:30:53 AM
I've just tried to send my PLE from STEX to my new generated paper wallet on https://www.plenteum.com/paper-wallet-generator.html
It sais "Withdrawal Error"
I'm waiting for the response from STEX support
It sais "Withdrawal Error"
I'm waiting for the response from STEX support
March 17, 2020, 05:56:58 PM
STEX has delisted this coin, devs has to find a new exchange with good volume asap
and do not even think about adding another pair beside BTC, please
also, do something with the algo, cause the merge mining story is not good at all
and do not even think about adding another pair beside BTC, please
also, do something with the algo, cause the merge mining story is not good at all
March 17, 2020, 01:54:26 PM
RXT pairs?
Why?
Why?
Hi there, Its not only a RXT Pairing. its BTC as well.
To answer on RXT. It is also RaptorXchange's Native token, so it would give RXT holders some incentive I believe(according to my understanding on their main website.
Hope to hear from you again soon
opening a new pair trading option can only ruin the price of PLE, cause now is at 1 sat, if we are looking on the stex exchange price
going under the 1 sats is a suicide for PLE
suicide for PLE was moving to chukwa, dumbest thing you could do with a coin ahaha your coin aint going to get better merge mining on a pyrimd scam. This coin has now just become a scam coin >>>>DO NOT MINE THIS COIN<<<<
lol
February 29, 2020, 04:22:47 AM
RXT pairs?
Why?
Why?
Hi there, Its not only a RXT Pairing. its BTC as well.
To answer on RXT. It is also RaptorXchange's Native token, so it would give RXT holders some incentive I believe(according to my understanding on their main website.
Hope to hear from you again soon
opening a new pair trading option can only ruin the price of PLE, cause now is at 1 sat, if we are looking on the stex exchange price
going under the 1 sats is a suicide for PLE
suicide for PLE was moving to chukwa, dumbest thing you could do with a coin ahaha your coin aint going to get better merge mining on a pyrimd scam. This coin has now just become a scam coin >>>>DO NOT MINE THIS COIN<<<<
September 29, 2019, 01:07:27 PM
RXT pairs?
Why?
Why?
Hi there, Its not only a RXT Pairing. its BTC as well.
To answer on RXT. It is also RaptorXchange's Native token, so it would give RXT holders some incentive I believe(according to my understanding on their main website.
Hope to hear from you again soon
opening a new pair trading option can only ruin the price of PLE, cause now is at 1 sat, if we are looking on the stex exchange price
going under the 1 sats is a suicide for PLE
September 28, 2019, 09:44:43 PM
RXT pairs?
Why?
Why?
Hi there, Its not only a RXT Pairing. its BTC as well.
To answer on RXT. It is also RaptorXchange's Native token, so it would give RXT holders some incentive I believe(according to my understanding on their main website.
Hope to hear from you again soon
September 27, 2019, 08:06:53 PM
RXT pairs?
Why?
Why?
September 27, 2019, 01:14:41 PM
Hi All.
Good news! We are going to be listed on a new exchange soon!
Here is the official tweet from Raptor Xchange
https://twitter.com/RaptorXchange/status/1177535948881563648
Good news! We are going to be listed on a new exchange soon!
Here is the official tweet from Raptor Xchange
https://twitter.com/RaptorXchange/status/1177535948881563648
September 17, 2019, 06:20:46 AM
Plenteum use cases
As most of you are probably already aware, we are an African coin, conceived and born in South Africa.
Africa faces numerous challenges, both economically and operationally due to a number of factors, including;
- Lack of governance
- Lack of accountability
- Corruption
- Informal Traders and Markets
- Lack of Basic Education
Our ultimate end goal with Plenteum Application Services is to allow for simplified implementation of solutions that cater to, or mitigate against, the risks that these challenge pose to economic growth and upliftment in the region.
Working with our partner entities, we have identified and run test scenario’s against a number of possible and probable usages of the technology stack to build the solutions they need to solve these very real challenges. This includes, but again is not limited to, transaction throughput rates, permission based security, configuration options and data storage and protection of private data on the network.
Specific details will be revealed when we are able, but in summary we’re working on the following:
1. An Identity Solution
This is a consolidated identity solution, that allows for various entities to request KYC and identity information for end users, with the end users permission in every instance. Many, many people in Africa lack basic identity information due to not being registered in national registers, not having any formal accommodation arrangements or bank accounts and utilising barter systems in their daily lives. However, the majority of these people do have limited access to online services through mobile devices predominantly. By linking biometric data and leveraging mobile device capabilities, this will enable entities to identify and register individuals for their own services, as well as leverage identity verifications made by other platform users (with the end users permission) to ease the administration burden. This aspect of the network enables many other services to be delivered on top of this, such as:
2. Micro Banking and B2B Lending solutions
Targeting the very hard to reach informal markets in Africa specifically, our solutions will enable informal traders to register and provide KYC for loan applicants, receive tradeable and transferrable digital tokens, tethered to and backed by the local market currency (it’s important to reiterate here that in under educated markets, crypto-currencies are not understood and it will always be very difficult to gain traction purely with a crypto-currency due to simple lack of understanding). These tokens can then be swopped for local currency cash using Informal Merchants as Micro Banking Agents (through Mobile App Wallets), traded directly with other users or transferred back to the original lender as re-payment.
3. Online retail services
Simple online payment gateway integrations allowing for payments to be made in digitised tokens tethered to local currencies and/or Plenteum itself where enabled.
4. Proof of Ownership (Provenance)
Proof of ownership of real-world physical assets can be a daily challenge in Africa. Transferring of those assets between individuals and entities often goes undocumented and results in a reduction in value, or largely increased cost associated with future transfers as this often requires significant manual documentation and filing & beuaracratic “red-tape” processes.
Assets such as vehicles, real-estate, jewellery etc. can be registered, identified with detail and transferred between end users at a lower cost, maintaining a complete history of ownership and ultimately a full provenance record of the physical asset and any changes associated with it. This allows these markets access to services such as insurance, re-finance, loans where collateral is required and many others often not possible or difficult to access today.
As already mentioned, we’ve also been working on our Core Software, a new Website and new Mobile wallets.
As most of you are probably already aware, we are an African coin, conceived and born in South Africa.
Africa faces numerous challenges, both economically and operationally due to a number of factors, including;
- Lack of governance
- Lack of accountability
- Corruption
- Informal Traders and Markets
- Lack of Basic Education
Our ultimate end goal with Plenteum Application Services is to allow for simplified implementation of solutions that cater to, or mitigate against, the risks that these challenge pose to economic growth and upliftment in the region.
Working with our partner entities, we have identified and run test scenario’s against a number of possible and probable usages of the technology stack to build the solutions they need to solve these very real challenges. This includes, but again is not limited to, transaction throughput rates, permission based security, configuration options and data storage and protection of private data on the network.
Specific details will be revealed when we are able, but in summary we’re working on the following:
1. An Identity Solution
This is a consolidated identity solution, that allows for various entities to request KYC and identity information for end users, with the end users permission in every instance. Many, many people in Africa lack basic identity information due to not being registered in national registers, not having any formal accommodation arrangements or bank accounts and utilising barter systems in their daily lives. However, the majority of these people do have limited access to online services through mobile devices predominantly. By linking biometric data and leveraging mobile device capabilities, this will enable entities to identify and register individuals for their own services, as well as leverage identity verifications made by other platform users (with the end users permission) to ease the administration burden. This aspect of the network enables many other services to be delivered on top of this, such as:
2. Micro Banking and B2B Lending solutions
Targeting the very hard to reach informal markets in Africa specifically, our solutions will enable informal traders to register and provide KYC for loan applicants, receive tradeable and transferrable digital tokens, tethered to and backed by the local market currency (it’s important to reiterate here that in under educated markets, crypto-currencies are not understood and it will always be very difficult to gain traction purely with a crypto-currency due to simple lack of understanding). These tokens can then be swopped for local currency cash using Informal Merchants as Micro Banking Agents (through Mobile App Wallets), traded directly with other users or transferred back to the original lender as re-payment.
3. Online retail services
Simple online payment gateway integrations allowing for payments to be made in digitised tokens tethered to local currencies and/or Plenteum itself where enabled.
4. Proof of Ownership (Provenance)
Proof of ownership of real-world physical assets can be a daily challenge in Africa. Transferring of those assets between individuals and entities often goes undocumented and results in a reduction in value, or largely increased cost associated with future transfers as this often requires significant manual documentation and filing & beuaracratic “red-tape” processes.
Assets such as vehicles, real-estate, jewellery etc. can be registered, identified with detail and transferred between end users at a lower cost, maintaining a complete history of ownership and ultimately a full provenance record of the physical asset and any changes associated with it. This allows these markets access to services such as insurance, re-finance, loans where collateral is required and many others often not possible or difficult to access today.
As already mentioned, we’ve also been working on our Core Software, a new Website and new Mobile wallets.
September 16, 2019, 02:20:44 AM
Introducing: Plenteum Application Services
We understand that as things stand today, there is no “one size fits all” approach that caters for all potential distributed ledger technology applications and use cases. Open public blockchains such as Bitcoin or our own Plenteum Core Blockchain rely on a Proof of Work algorithm to validate transactions, and in isolation are potentially limited by physical design constraints that make it almost impossible(or extremely difficult) to use these blockchain networks and their primary currencies as a method of proof for anything other than payments in the native crypto-currency of that network. Coupled with that, price volatility, transaction speed and transaction cost are seen as barriers to real world utility.
Plenteum Application Services is an ecosystem of different, but complimentary technology stacks, utilizing open source technologies that are being actively researched and developed to mitigate against the already mentioned barriers to real world utility. By leveraging these technologies, we are able to create a unique experience for our users, and provide Blockchain-as-a-Service solutions for both Public and Private use-cases in different industries.
In a nutshell, Plenteum App Services provides a set of API’s, integration helpers (SDK’s in Python & Node.JS so far) and Boilerplate applications that are dependent on underlying blockchain networks that enable simplified setup and operation of independent and inter-dependant blockchain based services. This will allow new and existing users to make use of our suite of tools with clear integration guidelines and processes.
It’s built on Hyperledger Iroha at is core (Version 1.1 for current testnet). We have been doing constant R&D for how different use cases can be implemented using a Proof of Authority Sidechain / Parachain as a scalable solution and an easy but robust Permissioned Distributed Ledger, that allows for careful crafting of assets, domains, user accounts & most importantly user permissions, which can be assigned in “permission groups” or roles depending on required functionality.
The vast set of commands & queries with the unique YAC (Yet Another Consensus) BFT algorithm has allowed internal Proof of Concepts that would not have been possible or at least taken a vast amount of time to carefully plan and develop, and the mature set of libraries available from Hyperledger Iroha has accelerated things to the point where we are approaching readiness for public beta testing.
The components behind Plenteum App Services are tightly integrated with each other at varying levels of operation. For purposes of explanation these can be defined in terms of layers:
Layer 1: The Plenteum Blockchain (Master Blockchain)
Plenteum serves as the Main Payment Settlements Currency on the extended network(s). Costs & Fees are calculated via the API(s) and the user + transactional data gets stored on our ID Network (see below).
Layer 2: The Plenteum Asset Platform & ID Network (Iroha)
P-o-A (Proof of Authority) Public & Private Permissioned ledgers. The core service where users manage their accounts, create assets and transfer those assets between participants.
Layer 3: API’s and Helper Libraries
Purpose built, easy to use APIs and Helper libraries are created for the sole use of interacting with PLE App Services. These can be easily customized & extended for each use case, resulting in a standardised environment where other ID Network users are able to interact with domains, their accounts and assets.
Layer 4: End User Applications
These are various purpose built and boilerplate applications that facilitate development and interaction with the various elements of the network. They include, but are not limited to Mobile Wallet & Network User management apps, Web Administration Portals, SMS & USSD Gateways, Authentication helpers etc..
In a future series of posts, we will break each of these layers down into more detail, explaining the component parts and how these layers interact with each other to provide real world utility.
Staking PLE
In order to run a Parachain (Iroha) node, PLE will need to be staked. Stakers, or App Services Node operators will earn a percentage of the total income the entire network generates from asset registration, asset transfer and/or transaction fees on the Public Assets Platform & ID Network.
More details on Staking PLE and how to setup the Iroha nodes will be provided in due course.
We understand that as things stand today, there is no “one size fits all” approach that caters for all potential distributed ledger technology applications and use cases. Open public blockchains such as Bitcoin or our own Plenteum Core Blockchain rely on a Proof of Work algorithm to validate transactions, and in isolation are potentially limited by physical design constraints that make it almost impossible(or extremely difficult) to use these blockchain networks and their primary currencies as a method of proof for anything other than payments in the native crypto-currency of that network. Coupled with that, price volatility, transaction speed and transaction cost are seen as barriers to real world utility.
Plenteum Application Services is an ecosystem of different, but complimentary technology stacks, utilizing open source technologies that are being actively researched and developed to mitigate against the already mentioned barriers to real world utility. By leveraging these technologies, we are able to create a unique experience for our users, and provide Blockchain-as-a-Service solutions for both Public and Private use-cases in different industries.
In a nutshell, Plenteum App Services provides a set of API’s, integration helpers (SDK’s in Python & Node.JS so far) and Boilerplate applications that are dependent on underlying blockchain networks that enable simplified setup and operation of independent and inter-dependant blockchain based services. This will allow new and existing users to make use of our suite of tools with clear integration guidelines and processes.
It’s built on Hyperledger Iroha at is core (Version 1.1 for current testnet). We have been doing constant R&D for how different use cases can be implemented using a Proof of Authority Sidechain / Parachain as a scalable solution and an easy but robust Permissioned Distributed Ledger, that allows for careful crafting of assets, domains, user accounts & most importantly user permissions, which can be assigned in “permission groups” or roles depending on required functionality.
The vast set of commands & queries with the unique YAC (Yet Another Consensus) BFT algorithm has allowed internal Proof of Concepts that would not have been possible or at least taken a vast amount of time to carefully plan and develop, and the mature set of libraries available from Hyperledger Iroha has accelerated things to the point where we are approaching readiness for public beta testing.
The components behind Plenteum App Services are tightly integrated with each other at varying levels of operation. For purposes of explanation these can be defined in terms of layers:
Layer 1: The Plenteum Blockchain (Master Blockchain)
Plenteum serves as the Main Payment Settlements Currency on the extended network(s). Costs & Fees are calculated via the API(s) and the user + transactional data gets stored on our ID Network (see below).
Layer 2: The Plenteum Asset Platform & ID Network (Iroha)
P-o-A (Proof of Authority) Public & Private Permissioned ledgers. The core service where users manage their accounts, create assets and transfer those assets between participants.
Layer 3: API’s and Helper Libraries
Purpose built, easy to use APIs and Helper libraries are created for the sole use of interacting with PLE App Services. These can be easily customized & extended for each use case, resulting in a standardised environment where other ID Network users are able to interact with domains, their accounts and assets.
Layer 4: End User Applications
These are various purpose built and boilerplate applications that facilitate development and interaction with the various elements of the network. They include, but are not limited to Mobile Wallet & Network User management apps, Web Administration Portals, SMS & USSD Gateways, Authentication helpers etc..
In a future series of posts, we will break each of these layers down into more detail, explaining the component parts and how these layers interact with each other to provide real world utility.
Staking PLE
In order to run a Parachain (Iroha) node, PLE will need to be staked. Stakers, or App Services Node operators will earn a percentage of the total income the entire network generates from asset registration, asset transfer and/or transaction fees on the Public Assets Platform & ID Network.
More details on Staking PLE and how to setup the Iroha nodes will be provided in due course.
September 16, 2019, 02:05:12 AM
Glad to read your news and that you have an active developement running on
I’m interested in Your Staking PLE program
When are planning to run it so I can start staking?
I’m interested in Your Staking PLE program
When are planning to run it so I can start staking?
Good Day big_daddy.
At this moment we still working on a few things to ensure we got the staking side right.
PLE staking will also be done via our PLE App Services, or more specifically, the Plenteum Identity Network. (PLE IDN).
Plenteum ID Network & Asset Platform will be key in our staking implementation, which is currently built upon Hyperledger Iroha (v1.1).
This has allowed for interesting Proof of Concepts including a KYC solution we will first most likely test and roll out in South Africa (the current dev team are South Africa based). so the challenges we facing with the ever epic, "adoption" will be thoroughly put thru its tests.
Apologies for not being able to give a date, but will ensure you are in the loop.
Kind Regards
September 13, 2019, 06:27:20 AM
Glad to read your news and that you have an active developement running on
I’m interested in Your Staking PLE program
When are planning to run it so I can start staking?
I’m interested in Your Staking PLE program
When are planning to run it so I can start staking?
September 12, 2019, 09:06:14 AM
Please share some details about the project. Investors? Mentors? What are your plans for this?
Hi there, you can read up a bit more on medium and also join us on discord or telegram.
https://medium.com/@whassupza/roundup-september-2019-6d13640d2477
September 12, 2019, 08:59:14 AM
Hi All.
Please see our latest round up article.
Hopefully this answers most of your questions!
We have been busy and are finally in the position to provide an update.
https://medium.com/@whassupza/roundup-september-2019-6d13640d2477
Please see the section regarding Plenteum Application Services as its the core section detailing our use cases we've identified and started working on solutions for.
Please see our latest round up article.
Hopefully this answers most of your questions!
We have been busy and are finally in the position to provide an update.
https://medium.com/@whassupza/roundup-september-2019-6d13640d2477
Please see the section regarding Plenteum Application Services as its the core section detailing our use cases we've identified and started working on solutions for.
August 30, 2019, 11:39:39 AM
August 29, 2019, 12:12:42 PM
Yes, not good situation
This is the main reason why we are sitting with no volume at 1 sat for months
August 29, 2019, 11:57:40 AM
August 11, 2019, 03:21:31 PM
please, do something with the algo
this merged mining possibility is killing the value of PLE
this merged mining possibility is killing the value of PLE
August 08, 2019, 11:24:43 AM
Release v0.4.5 Import Update
A friendly reminder to all users and pool operates to please update to the latest release version
https://github.com/plenteum/plenteum/releases/tag/v0.4.5
Special Notes
Please note, the build directions have changed, refer to the main Readme for instructions.
Upgrade to this release is required
Network Upgrade at Block 280,000
The v0.4.5 release of the core Plenteum software activates a network upgrade at block 280,000 that includes the following:
changed the difficulty algorithm parameters to allow for much faster network hashrate updates when large volumes of hash rate join or leave the network.
forces the verification of the signature counts on transactions send throughout the network.
helps reduce the risk of blockchain bloat from malformed transactions.
restricts transaction extra to a maximum of 1,0240 bytes to prevent chain storage bloat.
activates logic immediately that stops transactions exceeding this size limit from entering the transaction pool or being selected during the getblocktemplate calls; however, until block 280,000 transactions included in a block may still have transaction extra data exceeding the 1,0240 byte limit.
Pools, miners, and services can do their part by upgrading their daemons as soon as possible.
Release Notes
General Updates
Implements fork at 280,000 to reject new transactions with TX_EXTRA data > 1,0240 bytes and to reject new transactions where the signature count is incorrect for the number of inputs in the transaction.
Updates difficulty algorithm adjustment speed at height 280,000
Implements blockchain bloat protection from malformed transactions
Renamed PAGE_SIZE parameter in slow-hash functions that was causing errors when building for some users
Activated compiler cache for AppVeyor CI builds
Resolved a few edge case bugs whereby block synchronization may fall-through to different code paths
Resolved issue in AARCH64 builds that prevent the daemon from syncing to 100% height
Improved Mnemonics compilation speed
Resolved locale specific issue in Windows error messages
Updated to use platform independent randomness sources
Limits TX_EXTRA data field on transactions to <= 1,0240 bytes
CN Soft Shell algorithm altered (as yet unused by Plenteum) to allow for the user of CPU/GPU mining software
Removed all references to LWMA3 from the codebase to avoid any confusion about Difficulty algorithms in use
Resolved issue in some OSX build environments where building with the latest Xcode failed
Resolved an issue in the CMake build directions that were causing issues in a rare number of circumstances.
Added fundamental SQLite3 support into the project
Project now builds under MSVC 2019
Project no linked statically against OpenSSL for zedwallet-beta and wallet-api to facilitate encrypted communication with a node.
Upgraded MiniUPNP dependency from v1.9 to v2.1. Thanks @rixombea
Upgraded Crypto++ dependency to v8.2. Thanks @thinkpol2
Resolved issue whereby Release builds enabled assert() usage
Reorganized source code structure for better modularization of core libraries
Plenteumd Updates
Update core software to allow difficulty updates to NOT rely on block major version.
Resolved issue regarding consistent logging.
Increased the log level of the daemon when existing to provide insight and better error reporting when the daemon appears to hang while exiting.
Resolved issue with imprecision in fork countdown in status command.
Added optional blockCount parameter to getwalletsyncdata method.
Resolved various issues regarding Lite Blocks propagation.
Resolved Block Transactions Blob Shuffle.
Resolved Timestamp Locked Input Transactions.
Added --resync CLI argument that makes it easier to perform a full resync than searching for and deleting the data directory.
Added --rewind-to-height # CLI argument to allow for rewinding the local blockchain to a specific height thereby allowing us to overcome DB corruption errors.
Added --p2p-reset-peerstate CLI argument to allow for clearing the p2p state information.
Added support for lz4 compression in RocksDB backend.
To use, specify --db-enable-compression as a CLI argument.
Added experimental feature to allow the use of RocksDB for the local blockchain cache that replaces the .bin files.
Added experimental feature to allow the use of SQLite3 for the local blockchain cache that replaces the .bin files.
Updated JSON serialization methods.
zedwallet Updates
N/A
zedwallet-beta Updates
Replaced wallet saving/loading with rapidjson library.
Optimized synchronization flow logic.
Resolved edge case where wallet crashes when using a view wallet.
Added the ability to return the transaction private key of a transaction you have sent. If you reset or rebuild your wallet, this option will not work.
Added additional logging facilities.
Resolved issue with the display of the future unlock time in the UI if the input is locked as it comes in.
Resolved Prune spent inputs after some period of time from WalletBackend.
Resolved Rare Transaction Double Add Bug in WalletBackend.
Resolved Support Blockchain cache API in Nigel.
Resolved Added SSL support for talking to remote node(s). Activate it with a node via the --ssl CLI argument.
Resolved WalletBackend syncing doesn't remain O(1) when increasing the number of wallets.
Resolved Small bug in getFusionTransactionInputs().
Better daemon address parsing.
Refactored common utilities.
Added wallet synchronization backoff mechanism in the event that there is trouble retrieving blocks from the node.
Allow node to return earlier blocks during initial sync when scan height is specified.
Updated JSON serialization methods.
Aligned backup keys prompts to match current zedwallet order.
Resolved issue whereby the node fee was not being redectected correctly on swap of node.
wallet-service Updates
Restored -l CLI argument for the --log-file option.
Updated JSON serialization methods.
Resolved issue with opening View Only wallets in wallet-service.
wallet-api Updates
Added /balances endpoint.
Added optional unlock time parameter to /send/advanced endpoint.
Now returns the privateSpendKey when creating a new address.
Replaced wallet saving/loading with rapidjson library.
Resolved an error whereby two wallet-api instances attempted to share the same bind port and address.
Optimized synchronization flow logic.
Various bug fixes to improve stability and overall experience.
Resolved edge case where wallet crashes when using a view wallet.
Added new /address/validate endpoint.
Enhanced endpoints to allow the wallet to be open or closed depending on the endpoint used.
Added additional logging facilities.
Added publicSpendKey to /addresses/create.
Now performs additional validation of parameters on numerous endpoint calls.
Resolved Prune spent inputs after some period of time from WalletBackend.
Resolved Rare Transaction Double Add Bug in WalletBackend.
Resolved Support Blockchain cache API in Nigel.
Added SSL support for talking to remote node(s). Activate it with a node via the --ssl CLI argument.
Resolved WalletBackend syncing doesn't remain O(1) when increasing the number of wallets.
Resolved Small bug in getFusionTransactionInputs().
Added wallet synchronization backoff mechanism in the event that there is trouble retrieving blocks from the node.
Allow node to return earlier blocks during initial sync when scan height is specified.
Resolved issue whereby the node fee was not being redectected correctly on swap of node.
miner Updates
N/A
cryptotest Updates
Cleaned up and optimized duplicated code
Added benchmarks for underivePublicKey and generateKeyDerivation
How To Sync Quickly
Download the latest checkpoints.csv here https://github.com/plenteum/checkpoints/raw/master/checkpoints.csv
Place checkpoints.csv in the same folder as your Plenteumd daemon
Run Plenteumd with checkpoints added like this:
Linux, Apple ./Plenteumd --load-checkpoints checkpoints.csv
Windows Plenteumd.exe --load-checkpoints checkpoints.csv
Exchanges:
https://app.stex.com/en/basic-trade/pair/BTC/PLE/1D
https://fcbaccount.com/exchange
A friendly reminder to all users and pool operates to please update to the latest release version
https://github.com/plenteum/plenteum/releases/tag/v0.4.5
Special Notes
Please note, the build directions have changed, refer to the main Readme for instructions.
Upgrade to this release is required
Network Upgrade at Block 280,000
The v0.4.5 release of the core Plenteum software activates a network upgrade at block 280,000 that includes the following:
changed the difficulty algorithm parameters to allow for much faster network hashrate updates when large volumes of hash rate join or leave the network.
forces the verification of the signature counts on transactions send throughout the network.
helps reduce the risk of blockchain bloat from malformed transactions.
restricts transaction extra to a maximum of 1,0240 bytes to prevent chain storage bloat.
activates logic immediately that stops transactions exceeding this size limit from entering the transaction pool or being selected during the getblocktemplate calls; however, until block 280,000 transactions included in a block may still have transaction extra data exceeding the 1,0240 byte limit.
Pools, miners, and services can do their part by upgrading their daemons as soon as possible.
Release Notes
General Updates
Implements fork at 280,000 to reject new transactions with TX_EXTRA data > 1,0240 bytes and to reject new transactions where the signature count is incorrect for the number of inputs in the transaction.
Updates difficulty algorithm adjustment speed at height 280,000
Implements blockchain bloat protection from malformed transactions
Renamed PAGE_SIZE parameter in slow-hash functions that was causing errors when building for some users
Activated compiler cache for AppVeyor CI builds
Resolved a few edge case bugs whereby block synchronization may fall-through to different code paths
Resolved issue in AARCH64 builds that prevent the daemon from syncing to 100% height
Improved Mnemonics compilation speed
Resolved locale specific issue in Windows error messages
Updated to use platform independent randomness sources
Limits TX_EXTRA data field on transactions to <= 1,0240 bytes
CN Soft Shell algorithm altered (as yet unused by Plenteum) to allow for the user of CPU/GPU mining software
Removed all references to LWMA3 from the codebase to avoid any confusion about Difficulty algorithms in use
Resolved issue in some OSX build environments where building with the latest Xcode failed
Resolved an issue in the CMake build directions that were causing issues in a rare number of circumstances.
Added fundamental SQLite3 support into the project
Project now builds under MSVC 2019
Project no linked statically against OpenSSL for zedwallet-beta and wallet-api to facilitate encrypted communication with a node.
Upgraded MiniUPNP dependency from v1.9 to v2.1. Thanks @rixombea
Upgraded Crypto++ dependency to v8.2. Thanks @thinkpol2
Resolved issue whereby Release builds enabled assert() usage
Reorganized source code structure for better modularization of core libraries
Plenteumd Updates
Update core software to allow difficulty updates to NOT rely on block major version.
Resolved issue regarding consistent logging.
Increased the log level of the daemon when existing to provide insight and better error reporting when the daemon appears to hang while exiting.
Resolved issue with imprecision in fork countdown in status command.
Added optional blockCount parameter to getwalletsyncdata method.
Resolved various issues regarding Lite Blocks propagation.
Resolved Block Transactions Blob Shuffle.
Resolved Timestamp Locked Input Transactions.
Added --resync CLI argument that makes it easier to perform a full resync than searching for and deleting the data directory.
Added --rewind-to-height # CLI argument to allow for rewinding the local blockchain to a specific height thereby allowing us to overcome DB corruption errors.
Added --p2p-reset-peerstate CLI argument to allow for clearing the p2p state information.
Added support for lz4 compression in RocksDB backend.
To use, specify --db-enable-compression as a CLI argument.
Added experimental feature to allow the use of RocksDB for the local blockchain cache that replaces the .bin files.
Added experimental feature to allow the use of SQLite3 for the local blockchain cache that replaces the .bin files.
Updated JSON serialization methods.
zedwallet Updates
N/A
zedwallet-beta Updates
Replaced wallet saving/loading with rapidjson library.
Optimized synchronization flow logic.
Resolved edge case where wallet crashes when using a view wallet.
Added the ability to return the transaction private key of a transaction you have sent. If you reset or rebuild your wallet, this option will not work.
Added additional logging facilities.
Resolved issue with the display of the future unlock time in the UI if the input is locked as it comes in.
Resolved Prune spent inputs after some period of time from WalletBackend.
Resolved Rare Transaction Double Add Bug in WalletBackend.
Resolved Support Blockchain cache API in Nigel.
Resolved Added SSL support for talking to remote node(s). Activate it with a node via the --ssl CLI argument.
Resolved WalletBackend syncing doesn't remain O(1) when increasing the number of wallets.
Resolved Small bug in getFusionTransactionInputs().
Better daemon address parsing.
Refactored common utilities.
Added wallet synchronization backoff mechanism in the event that there is trouble retrieving blocks from the node.
Allow node to return earlier blocks during initial sync when scan height is specified.
Updated JSON serialization methods.
Aligned backup keys prompts to match current zedwallet order.
Resolved issue whereby the node fee was not being redectected correctly on swap of node.
wallet-service Updates
Restored -l CLI argument for the --log-file option.
Updated JSON serialization methods.
Resolved issue with opening View Only wallets in wallet-service.
wallet-api Updates
Added /balances endpoint.
Added optional unlock time parameter to /send/advanced endpoint.
Now returns the privateSpendKey when creating a new address.
Replaced wallet saving/loading with rapidjson library.
Resolved an error whereby two wallet-api instances attempted to share the same bind port and address.
Optimized synchronization flow logic.
Various bug fixes to improve stability and overall experience.
Resolved edge case where wallet crashes when using a view wallet.
Added new /address/validate endpoint.
Enhanced endpoints to allow the wallet to be open or closed depending on the endpoint used.
Added additional logging facilities.
Added publicSpendKey to /addresses/create.
Now performs additional validation of parameters on numerous endpoint calls.
Resolved Prune spent inputs after some period of time from WalletBackend.
Resolved Rare Transaction Double Add Bug in WalletBackend.
Resolved Support Blockchain cache API in Nigel.
Added SSL support for talking to remote node(s). Activate it with a node via the --ssl CLI argument.
Resolved WalletBackend syncing doesn't remain O(1) when increasing the number of wallets.
Resolved Small bug in getFusionTransactionInputs().
Added wallet synchronization backoff mechanism in the event that there is trouble retrieving blocks from the node.
Allow node to return earlier blocks during initial sync when scan height is specified.
Resolved issue whereby the node fee was not being redectected correctly on swap of node.
miner Updates
N/A
cryptotest Updates
Cleaned up and optimized duplicated code
Added benchmarks for underivePublicKey and generateKeyDerivation
How To Sync Quickly
Download the latest checkpoints.csv here https://github.com/plenteum/checkpoints/raw/master/checkpoints.csv
Place checkpoints.csv in the same folder as your Plenteumd daemon
Run Plenteumd with checkpoints added like this:
Linux, Apple ./Plenteumd --load-checkpoints checkpoints.csv
Windows Plenteumd.exe --load-checkpoints checkpoints.csv
Exchanges:
https://app.stex.com/en/basic-trade/pair/BTC/PLE/1D
https://fcbaccount.com/exchange
Jump to: