Hello, @gimre here. We should probably change the way we display public keys in all possible applications/tools/etc. But before I dive into this, let's refresh your memory about addresses. This part is Symbol oriented, but it's also true for NEM. Addresses (again) Addresses in Symbol consist of 3 parts: 1-byte network prefix (0x68 byte in mainnet)

Observation After the production of block 4129631, block production on the NEM network slowed to a crawl. This situation was instigated by an unexpected transaction entering the Unconfirmed Transactions cache. When this transaction expired, block production went back to normal. We have identified the makeup of the unexpected transaction and how it entered the Unconfirmed Transactions cache. A multisig account configured with 1-of-2 multisig sent two conflicting transactaions. Assume that the two cosigners are named A and B and the multisig account is named M. Root Cause Analysis The following sequence of events occured:

Before any changes are deployed to Symbol mainnet or a new project gets launches on the blockchain, a test version is deployed to testnet first. Symbol test network(testnet) simulates the Symbol main network which gives developers and the community a chance to test features before real assets are used. Sai Testnet is the current testnet for Symbol. You can add a node and get test tokens from the Faucet. The Faucet allow an account to request up to 10k in test xym. If more token are needed to test or run a voting node, you can be requested from the Symbol's helpdesk on discord. It can be fun to have 3 or 4 million of test xym to splurge a bit, even though they carry no real-world value. Why should you create your own dev testnet? Creating and maintaining a Symbol testnet requires some work like certs and voting key renewals, so why bother setting up your own? These are some reasons you would want to setup your own dev testnet. Test Scenario - you might want to run specific test scenarios for your application. Let's say you want to fork the network and stall finalization to verify that your application also stops accepting deposits and withdrawals. Persistence - there is no guarantee that the testnet won't be reset. Symbol testnet is reset at least once a year to keep storage low. But it can also be reset if a major feature stops working. If your application requires the data kept for a longer time then a dev testnet would be better. Control Funds - your use case might require a large sum of funds like 500 Million xym. Even though there is the Faucet, requesting that much token is best done on dev testnet.

Greetings, Citizens of XYM City! Find the Japanese translation here. The Discovery On October 13th, Toshi reported some unexpected behavior to us on Discord in the #sdk-js channel. He had been comparing the outputs of the deprecated TypeScript SDK to the newer JavaScript SDK and noticed that the aggregate transaction hashes were being calculated differently. That...was not expected behavior. Even more concerning was the fact that they were both being accepted (and confirmed) by the network. Root Cause The team quickly identified two critical bugs - one in Catapult (the Symbol client), and one in the TypeScript and Java SDKs.

Throughout Symbol's development, we've used a large number of different languages. As part of regrouping and turning the ship, we've decided to cut back on the number of primary languages. Some choices will be less surprising than others. We hope this will facilitate hiring and improve intra-organizational mobility. We want to tear down those walls, Mr. Gorbachev! C++ catapult-client is the Symbol reference client and will continue to be developed and maintained in C++. We like C++ because it is a deterministic destruction language, which gives us fine grained control over memory usage. This allows us to optimize performance. C++ before and after 0x are almost different languages. Using RAII patterns, memory problems are almost almost a thing of the past.

Hi. 👋 You might know us as 🤖 Gimre, 🪓 Hatchet, and 🐆 Jaguar. Along with the rest of the Pirate crew, we're the team behind Symbol & NEM. Some of us are old hats, and some of us are fresh recruits, but we've all banded together under a common flag to dedicate ourselves to the research and development of the Symbol protocol, and the maintenance of the NEM protocol. In July of this year we announced the shutdown of NEM Group, the previous operational entity that had taken Symbol to mainnet. Alongside this, we announced our vision paper that outlined a new kind of transaction-specific sidechain (called subChains), our aspirations for Symbol, and the future of NEM. While the last four months have felt like an ongoing battle for the future of Symbol & NEM, we're pleased to announce that it is coming to an end. There's just one last thing to do before we set sail. But before that, a bit of context. 🏴‍☠️

NEM launched on March 31st, 2015, seeking to improve on the imperfections found in other chains at the time. It was one of the first non-turing complete chains to feature user-defined tokens (called mosaics), namespaces, multisignature accounts, and a P2P reputation system based on EigenTrust++. Its most notable contribution, however, remains the proof-of-importance consensus mechanism which sought to reward on-chain activity and deter the concentration of wealth commonly associated with proof-of-stake. From 2016 onwards, NEM marched towards Japan and became a viral phenomenon: it saw enterprise adoption under Tech Bureau; became an alternative payment option at local restaurants and global hotels; inspired art exhibits and community-run cafe's and even donation drives. Today, it remains a heavily-traded project with a global, loyal userbase that believes in the founding principles of the project: decentralization, financial freedom, and equality of opportunity. Six years later, we're finally bringing NEM out of BETA, and open-sourcing the project. The Road Forward NEM is currently going through its seventh hardfork: the Harlock update. Harlock is intended for NEM nodes to signal explicit support and desire for the merge of the NEM blockchain into Symbol as a 'subChain', a type of transaction-specific sidechain.

Summary: Catapult v1.0.2.0 is a pre-announced hotfix release to patch a bug in Symbol's finalization gadget. All users should update their nodes immediately. You can see our post-mortem here. Besides this fix, we've also merged in a few enhancements. Bugs Fixed: Fixes a bug in FinalizationContext around voting weight. Accounts that did not have voting keys in a current epoch (but did in the previous one) were included in the calculation of m_weight. Now they're correctly ignored. Fixes a bug that would cause nodes to crash when they ran out of voting keys.

Greetings, Citizens of XYM City! Finalization Background Finality is an important concept in blockchain - it's an assurance that a transaction cannot be altered, reversed, or canceled. Most chains (like Bitcoin) utilize probablistic finality - that is, the chances that your transaction can be modified lowers as time passes. In Symbol we have both probalistic finality and we have deterministic finality as a seperate gadget - a transaction is considered to be final once it has been included in a finalized block. In order to finalize a block, 2/3 of the active voting stake must vote on the block's hash. Voters are allowed to enter and exit the finalization process at will. Any membership changes are effective for the next epoch. In addition, the active voting stake is calculated at the end of each epoch and that amount is used as the denominator in the next epoch. Problem On Sunday, September 12th we noticed the network having trouble with finalizing epoch 361. This was not entirely surprising - we had expected this epoch to be a strong stress test for the finalization process.

We use a modified sane labelling scheme as proposed here by Dave Lunny, along with inspiration from ManageIQ. It's broken down into four different types of labels: status labels, release labels, type labels and change labels. SRC | NIPs have their own labelling schema which are defined [here](todo: make 'here'). Status Labels These are intended to cover a broad range of states that an issue may be in during different stages of development. Only one status label will be applied to a particular issue - for instance, something can't be both 'In Progress' and 'Abandoned'. Label

This is the first part in a two-part community Q&A with Gimre, Hatchet & Jaguar. The SuperNode Program 01: What’s happening with the SuperNode program? Why the delay? Why have the voting rewards been delayed? During the initial tokenomics work, there were some assumptions modeled on network price and activity that have (so far) not been the behavior we have observed on the current network. In light of this, as well as the new direction of subChains, we're revisiting our token and mechanism design to see if adjustments are needed to better balance the rewards and fees vs economic security provided by the network. Voting rewards and the SuperNode program are also being revisited as part of this effort. We will provide a full report when we've finished our analysis, but don't expect any new payments or programs until we've finished it. 02: Do some users of the network get treated differently to the rest of the community? If so, why?