[bisq-contrib] Testing release candidate v0.6

Thu Nov 9 16:13:16 UTC 2017

I will also help with testing.

Cheers

On 09/11/17 12:25, Christoph Atteneder wrote:
> I’ve just created a Spreadsheet as a starting point for our tests. We
> can easily extend it based on our
> requirements: https://docs.google.com/spreadsheets/d/18n6wV0g5MPTs9Xni0cFji8U34xV3O1IRPDEYZrluBuU/edit?usp=sharing
>
>
> Best,
>
> Christoph
>
>> Am 09.11.2017 um 11:03 schrieb Christoph Atteneder
>> <christoph.atteneder at gmail.com <mailto:christoph.atteneder at gmail.com>>:
>>
>> Hi Manfred!
>>
>> I know testing is always a pain-in-the-ass for every dev so we came
>> up with a QA department ;-). To make it less sucking I’ll jump in to
>> take a couple of the most common 
>> test scenarios and will update the click-prototypes and create new
>> ones for the other cases in parallel. What about putting the
>> scenarios into a Google Spreadsheet? I could set something up, so we
>> can use it for future releases as well. Who else want to help out? :-)
>>
>> Best,
>>
>> Christoph
>>
>>
>>> Am 09.11.2017 um 00:35 schrieb Manfred Karrer <mk at nucleo.io
>>> <mailto:mk at nucleo.io>>:
>>>
>>> The next release v0.6. gets ready for testing (Development branch).
>>> I would like that we do a profound testing because there are a lot
>>> of new features and it could easily break something.
>>> I would like to get a few contributors to help testing as more eyes
>>> will spot more and in the past we had a few times the issue that I
>>> needed to deploy a hotfix release to fix bugs I missed.
>>>
>>> To give a better idea about the task I would like to lay out a bit
>>> the test situation, challenges and a suggestion for a test plan.
>>>
>>> The complexity of testing Bisq lies mainly in the combination of the
>>> P2P network, Bitcoin network, user interaction and dealing with
>>> backward compatibility and different types of "consensus”. 
>>> All that makes unit test based testing very difficult (thats my main
>>> excuse why we have so few unit tests :-)). 
>>>
>>> One of the big challenges are the different levels of “consensus”
>>> and backward compatibility. There are several areas where code
>>> changes break verifications like in the P2P network data we use a
>>> hash of the data which gets signed and the signature need to match.
>>> If one user has a newer version with a new field added to such a
>>> class the hash of the object would be different and therefore the
>>> sig check would fail. That is just one example where we need to take
>>> care that changes are not breaking older version or make
>>> interactions between old and new clients incompatible. In the trade
>>> process there is a similar issue as the trade contract (json)
>>> gets hashed and verified by the peer. Any change here would let a
>>> trade fail. That caused for instance a problem in v.0.5.2 (email in
>>> some payment accounts was empty string in old version and omitted in
>>> new version because it was null causing a contract hash check failure). 
>>> Protobuffer is another area where we need to take care. Not handling
>>> new added fields correctly would also lead to problems.
>>>
>>> So how can we test such a beast without spending 2 years on writing
>>> a highly complex test environment?
>>>
>>> I do it with manually testing most of the possible use cases in many
>>> variants.
>>> Starting with the trade process between 2 peers and then going in
>>> more complex variations and other use cases.
>>>
>>> I start with RegTest only testing as that is the fastest. I also use
>>> first the DevEnv flags (DEV_MODE and USE_DEV_PRIVILEGE_KEYS) to make
>>> testing faster by avoiding popups and pre-filling some input fields
>>> like trade amount and price. Later I test without those flags to be
>>> sure to not miss important issues. I also start with a new data
>>> directory to have all reset.
>>> Later when I don’t find any more issues I move to Testnet or
>>> Mainnet. Testnet I did not use much because it was so unreliable
>>> with confirmation times but might be good as it comes with extreme
>>> situations (sometimes every few seconds new blocks, deep reorgs,
>>> people are testing new BTC features there,…).
>>>
>>> Important test variations are:
>>> - users are online or offline during trade
>>> - maker as buyers or seller
>>> - normal trade, disputed trade
>>> - interaction with user with older version
>>> - using Tor vs. not Tor (BitcoinJ)
>>> - RegTest, Testnet, Mainnet
>>> - Fiat trade, Altcoin trade
>>> - using password protection or not (was once a reason or a required
>>> hotfix as I did not test with pw protection)
>>> - funding a trade from internal wallet or external wallet (though
>>> that has never caused issues so far)
>>>
>>> Here is a list of the most important test scenarios:
>>> - Alice maker as buyer trades with Bob taker as seller, both are
>>> online all the time
>>> - Alice maker as seller trades with Bob taker as buyer, both are
>>> online all the time
>>> - Next is to test both cases that they are offline during the trade
>>> steps.
>>> - Next is that they open a dispute both with the online and offline
>>> cases
>>> - Next is to use one peer with an old version, one with a new version
>>> - Beside the trade use case I visit all screens and if there are
>>> some relevant user activities possible like setting up an account I
>>> test that. If there have been changes in the payment accounts it is
>>> needed to test setting up all the possible fiat accounts.
>>> - Testing the account screens. Password, backup, seed words,…
>>>
>>> Of course I try to focus on those areas where we changed something,
>>> but the basic use cases (trade, dispute) need to be tested always.
>>> When testing on Mainnet you need to take care to not interfere with
>>> real traders. I used usually payment methods or altcoins which are
>>> not used like Alipay or using very bad prices.
>>>
>>> So how could we distribute the testing to avoid that bugs slip through?
>>>
>>> I would like to have at least 2 devs who help me testing and do
>>> basically what I described above in their own style. Any input of
>>> ideas to make that less painful are welcome. 
>>> Automating those tests will be very hard and is not feasible for the
>>> near future but as soon we have enough resources it might of course
>>> become a topic. 
>>>
>>> So my question is who is willing to help me testing? With no B2X we
>>> have less time pressure but I want to get that release out in the
>>> next days anyway to get back to DAO work.
>>>
>>> Here I have written up summaries for describing and testing the big
>>> features:
>>> https://github.com/bisq-network/exchange/issues/998
>>> https://github.com/bisq-network/exchange/issues/999 
>>> https://github.com/bisq-network/exchange/issues/1000 
>>>
>>>
>>> Here are the current release notes:
>>>
>>> Big features:
>>> * Add support for Tor bridges and pluggable transports
>>> (https://github.com/bisq-network/exchange/issues/998)
>>> * Provide Bitcoin full nodes from Bisq developers
>>> (https://github.com/bisq-network/roles/issues/39) to protect against
>>> BitcoinJ vulernatibilty regarding B2X (BitcoinJ is blindly following
>>> longest PoW chain and not checking consensus rule violations). That
>>> also avoids the privacy issues with bloom filters.
>>> (https://github.com/bisq-network/exchange/issues/999)
>>> * Add account age verification scheme
>>> (https://github.com/bisq-network/proposals/blob/master/payment-account-age-witness.adoc,
>>> https://github.com/bisq-network/exchange/issues/1000)
>>>
>>> Changed fees, limits, security deposit:
>>> * Reduce DEFAULT_TAKER_FEE_IN_BASE_CUR from 0.003 BTC to 0.002 BTC
>>> (that is the base for a 1 BTC trade)
>>> * Lower miner fees by ee estiamtion adjustments (using maxDelay 20
>>> instead of 10 and taking average of 12 last fee results)
>>> * Lower miner fee by transaction size calculation. Instead of using
>>> 600 bytes as estimation of trade fee tx we create a dummy tx to get
>>> the exact size id funds are on the wallet, otherwise we use 260
>>> bytes for maker and 320 bytes for taker (deposit and payout tx are
>>> larger).
>>> * Reduce security deposit: DEFAULT_BUYER_SECURITY_DEPOSIT from 0.03
>>> BTC to 0.01 BTC; MAX_BUYER_SECURITY_DEPOSIT from 0.2 BTC 0.05 BTC,
>>> MIN_BUYER_SECURITY_DEPOSIT from 0.001 BTC to 0.0005 BTC;
>>> SELLER_SECURITY_DEPOSIT from 0.01 BTC to 0.003 BTC
>>> * Use new trade limits to reflect higher BTC price
>>>     Bank transfers: 0.25 BTC
>>>     Swish, OKPay, PerfectMoney, AliPay: 0.5 BTC
>>>     Altcoins 1 BTC (exception SiaFund as their price is about 3 BCT
>>> and it is not dividable, so we allow 4 BTC there)
>>> * Use new seed nodes and price relay nodes operated by different
>>> Bisq developers and bonded by BSQ
>>>
>>> Other features:
>>> * Show latest trade price in case no price from external market
>>> price providers is available. To be used only for informational
>>> purpose not for % based offers due price manipulation risks.
>>> * Enable Bisq DAO phase 1 on Bitcoin Testnet: BSQ genesis
>>> distribution, BSQ trading, BSQ used for paying trade fee, BSQ wallet
>>> with send, receive and tx list screens, dashboard
>>> * Add new languages: Chinese, Hungarian, Romanian, Russian, French,
>>> Turkish
>>> * Added new Altcoins: DECENT, Pranacoin, WACoins, ZenCash, Ellaism,
>>> Cryptonite, Terracoin, Internext
>>> * Add all missing countries (all global countries taken from
>>> https://restcountries.eu/rest/v2/all?fields=name;region;subregion;alpha2Code;languages)
>>> * Add OXT as BTC blockexplorer
>>> * Add filter for arbitrators, seed nodes and price relay nodes
>>> * Change pw length restriction
>>> * Change name of IOP to "Internet Of People"
>>> * Remove DOGE as base currency (zero trade activity)
>>> * Reduce number of seed nodes for LTC and DASH (very low trade activity)
>>> * Removed never-traded altcoins: Advanced Internet Blocks (AIB),
>>> Anoncoin (ANC), Anti (ANTI), AquariusCoin (ARCO), Argentum (ARG),
>>> Augur (REP), Battlestars (BATL), BigUp (BIGUP), BitAUD (BITAUD),
>>> BitCHF (BITCHF), BitCNY (BITCNY), BitEUR (BITEUR), BitGBP (BITGBP),
>>> BitHKD (BITHKD), BitNZD (BITNZD), BitSEK (BITSEK), BitSGD (BITSGD),
>>> BitSYNQ (SYNQ), BitShares (BTS), BitUSD (BITUSD), Blackcoin (BLK),
>>> Clams (CLAM), CloakCoin (CLOAK), Comet (CMT), Creditbit (CRBIT),
>>> Crown (CRW), Crypto Bullion (CBX), DIBCOIN (DIBC), Digibyte (DGB),
>>> Digital Rupees (DRS), DigixDAO Tokens (DGD), EOS (EOS), EUR Tether
>>> (EURT), Emercoin (EMC), Eternity (ENT), Europecoin (ERC),
>>> EverGreenCoin (EGC), Factom (FCT), FairCoin (FAIR), FlorinCoin
>>> (FLO), GameCredits (GAME), Gemz (GEMZ), Groestlcoin (GRS), Gulden
>>> (NLG), HOdlcoin (HODL), HunCoin (HNC), I/O Coin (IOC), JPY Tether
>>> (JPYT), Janus (JNS), Jumbucks (JBS), LTBcoin (LTBC), Maker (MKR),
>>> MarteXcoin (MXT), Moin (MOIN), Myriadcoin (XMY), NEM (XEM), Nevacoin
>>> (NEVA), NuShares (NSR), OKCash (OK), Omni (OMNI), Opal (OPAL),
>>> Particl (PART), Peercoin (PPC), Pinkcoin (PINK), PlatinumBar (XPTX),
>>> Plutons (PLU), PotCoin (POT), Primecoin (XPM), Radium (RADS),
>>> RealEst. Coin (REALEST), Ripple (XRP), Shift (SHIFT), Smileycoin
>>> (SMLY), SolarCoin (SLR), Steem Dollars (STEEMUSD), Stellar Lumens
>>> (XLM), StorjcoinX (SJCX), Stratis (STRAT), Swarm City Token (SWT),
>>> Syndicate (SYNX), Synereo (AMP), Triangles (TRI), USD Tether (USDT),
>>> VCoin (VCN), VPNCoin (VPN), Verge (XVG), VeriCoin (VRC), Waves
>>> (WAVES), Worldcoin (WDC), Xaurum (XAUR), YACCoin (YACC), YbCoin (YBC)
>>> * Many smaller improvements in the UI
>>>
>>> Bug fixes, code improvements:
>>> * Fix wrong date handlin gin trade statistics charts
>>> * Listen to bitcoin network for deposit and payout transaction in
>>> case the P2P message did not arrive
>>> * Support different keys for code signing in download-tool
>>> * Fix bug with missing MultiSigKey (findKeyFromPubKeyHash call was
>>> used instead of findKeyFromPubKey)
>>> * Fix missing persistence for trade statistic object in seed nodes
>>> * Fix but with offer sorting
>>> * Use smaller font and witdh for TAC window on very small screens 
>>> * Use netlayer Tor library (https://github.com/JesusMcCloud/netlayer/)
>>> * Improved build system 
>>>
>>> Br,
>>> Manfred
>>> _______________________________________________
>>> bisq-contrib mailing list
>>> bisq-contrib at lists.bisq.network <mailto:bisq-contrib at lists.bisq.network>
>>> https://lists.bisq.network/listinfo/bisq-contrib
>>
>
>
>
> _______________________________________________
> bisq-contrib mailing list
> bisq-contrib at lists.bisq.network
> https://lists.bisq.network/listinfo/bisq-contrib

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-contrib/attachments/20171109/375a30b7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.bisq.network/pipermail/bisq-contrib/attachments/20171109/375a30b7/attachment-0001.sig>