ARK Core v2.6 Community Testing Results And Winners

Our community-based feedback and issue reporting contest on Core v2.6 has come to an end. We’d like to thank everyone who helped and participated in this initial testing phase. More than 70 issues from the community were opened and have been resolved, which will net participants in total over $3,000 USD for reporting issues or improvement suggestions!

Core v2.6 is around the corner and the last step of this big adventure is the upcoming Release Candidate (RC) on Devnet which will run as a final test before we move to Mainnet.

The current plan is to deploy the RC on Devnet this Monday, the 13th of January 2020. This will run for a week or two before moving it to Mainnet, depending on any last issues or reports (when RC gets deployed on Devnet we will also go back to normal reporting for security vulnerabilities).

What’s Next for Core?

During the v2.6 development, we have been working on Core v3 in parallel. We are happy to say that Core v3 development is very far along and we will soon (after v2.6 settles on Mainnet) be making its codebase public! We want to get input and get it out in the open as soon as possible for community developers, testers & bridgechains to start helping and playing with. You can also expect a lot of cool Core v3 related blog posts getting published each week!

Now to announce our winners and eligible participants of the Core v2.6 testing bug bounty program!

Winners & Participants

#1 Dated — TOTAL $2,045 USD ($1,045 + $1,000 BONUS)

• Total eligible issues reported 48 worth $1,045
  Number of tier 4 issues: 37 = $ 555
  Number of tier 3 issues: 7 = $ 210
  Number of tier 2 issues: 3 = $ 180
  Number of tier 1 issues: 1 = $ 100

#2 Lemii — TOTAL $810 USD ($310 + $500 BONUS)

• Total eligible issues reported 12 worth $310
  Number of tier 4 issues: 8 = $ 120
  Number of tier 3 issues: 3 = $ 90
  Number of tier 1 issues: 1 = $ 100

#3 Alessiodf — TOTAL $415 USD ($165 + $250 BONUS)

• Total eligible issues reported 5 worth $165
  Number of tier 4 issues: 1 = $ 15
  Number of tier 3 issues: 3 = $ 90
  Number of tier 2 issues: 1 = $ 60

#4 Biolypl — TOTAL $30 USD

• Total eligible issues reported 2 worth $30
  Number of tier 4 issues: 2 = $ 30

#5 Deanpress — TOTAL $15 USD

• Total eligible issues reported 1 worth $15
  Number of tier 4 issues: 1 = $ 15

#6 Galperins4 — TOTAL $15 USD

• Total eligible issues reported 1 worth $15
  Number of tier 4 issues: 1 = $ 15

#7 Mudlee — TOTAL $15 USD

• Total eligible issues reported 1 worth $15
  Number of tier 4 issues: 1 = $ 15

Overview of resolved issues

Dated:

• username schema not enforced on all api endpoints

• orderBy not working with some camel cased iteratees

• businesses/{id} endpoint always returns data regardless of business attribute

• businesses/{id} and businesses/{id}/bridgechains accepts only publicKey

• businesses/{id} endpoint returns full wallet data

• bridgechains/:id endpoint can’t find bridgechain

• allow searching of businesses and bridgechains by isResigned

• inconsistent presence of isResigned property in api responses

• can’t apply bridgechain resignation or update without bootstrap

• vendorfield conversion from buffer to string in htlc transactions

• unclear core-magistrate transaction static fee mismatch error

• type of lockTransactionId in transaction schemas

• htlc refunds of bootstrapped locks cannot be applied to sender but increases nonce

• query params are ignored in wallets/{id}/locks cache

• no restrictions on orderBy param

• wrong meta data when querying with a page param bigger than pageCount

• allow filtering locks by status

• overly strict genericName regex

• discovery of expired locks

• duplicate ipfs hashes in db

• HtlcRefundTransactionHandler.revertForSender fails during bootstrap

• global ipfs hash uniqueness is not ensured

• resigned delegates cannot be unvoted

• resigning a delegate does not remove/clear delegate rank

• wallet attributes not updated after delegate resignation

• transactions/fees endpoint lists only fees of core typegroup

• no pluralization in recently added errors

• extend bridgechains search endpoint

• extend businesses search endpoint

• use core typegroup as default in transactions api

• typeFromSenderAlreadyInPool method disregards typeGroup

• hardcoded cap for maximum amount of transactions per multi payment

• vendorfield of locks returned as buffer by the api

• databaseservice connection not retrieved properly

• updating bridgechains emits “business.updated” event

• uniqueness of bridgechain names for the same business

• multiple business and bridgechain updates allowed in transaction pool

• concrete type hints instead of interface from core-interfaces

• businesses/{id}/bridgechains endpoint not implemented

• type of businessId and bridgechainId

• duplication of values in buildConstants()

• uniqueness of business name or website and combination thereof

• timestamp returned by locks endpoints

• default ordering of locks not sufficient

• peers api endpoint returns wrong data

• improve ordering of the peers api endpoint

• broadcasting block logs

• trailing slash(es) are not being removed

Lemii:

• Vendorfield value gets omitted when it exceeds maximum length

• Disallow duplicate genesisHash values for bridgechains

• No static fee is applied to Business and Bridgechain registration

• Redundant properties in genesisHash schema

• MaximumPaymentCountExceededError shows incorrect received amount

• Unicode characters U+0000 to U+0080 allowed in certain business and bridgechain fields

• Misleading error message when updating a bridgechain not registered by the same business

• Perform validation on the website field of a business registration/update

• Typegroup mismatch in /api/transactions/types endpoint and actual transaction data

• /api/peers endpoint incorrect paginated results

• Occassional 503 and 422 errors when opening last page of /api/delegates/{username|address|publicKey}/blocks

• Discussion: Set ‘Version: 2’ as default or make it easier to configure

Alessiodf:

• V1 tx in the AIP11 milestone activation round can prevent nodes starting

• TypeError: Cannot set property during Htlc Claim Transaction Handler.revertForSender

• Regression of Core-SV-027 in 2.6

• All peers will be disconnected at height 3963000

• High incidence of forks on devnet (due to postBlock throttling?)

Biolypl:

• Core unable to decrypt passphrase

• Example forger configuration command from documentation fails

Mudlee:

• Round saving error in 2.6.0-next.6

Deanpress

• Transaction API returns empty response when canEnterTransactionPool is false and no error is pushed by the transaction’s handler

Galperins:

• Sync from 0 does not work

Thank you again to all who participated! You are all ARK’s rockstars! 🌟

Read our new whitepaper! Follow us on social media ( Twitter|Facebook|Reddit ), join our community ( Slack | Discord ) and stay tuned to our blog on Medium and on Steemit.