Add types skeleton of coin selection and largestFirst algo implementation #121

paweljakubas · 2019-03-25T16:25:23Z

Issue Number

#92

Overview

I have added coin selection proposal for coin selection and fee calculation

Comments

src/Cardano/Wallet/CoinSelection.hs

akegalj · 2019-03-26T14:02:01Z

src/Cardano/Wallet/CoinSelection.hs

+
+estimateMaxTxInputs
+  :: ByteString
+    -- ^ Maximum size of a transaction


size of tx in bytestring - how should one interpret this ?

you are right, should be Bytes (memory unit), like in http://hackage.haskell.org/package/serokell-util-0.10.0/docs/src/Serokell.Data.Memory.Units.html#Byte

I wonder if we are ok with using serokell-utils or better define Bytes ourselves?

It's okay to use libraries (from Serokell or anyone) when they are sound and solve an actual problem. Here, serokell-util isn't really sound nor useful for most of the types or functions it provides IMO.

Here, a size could just be a Quantity "byte" Word32 if you really want to disambiguate the type. Yet, I believe it's not needed to implement largest first 🤔 ?

if it is not needed in the end I will definitely remove it. Otherwise, will rely on Quantity "byte" Word32

paweljakubas · 2019-03-27T19:02:48Z

just rebased to update the branch with master

KtorZ

Some good ideas in the test scenarios that would be better expressed as plain hand-written unit tests IMO;

KtorZ · 2019-03-27T14:23:57Z

src/Cardano/Wallet/CoinSelection/LargestFirst.hs

+    let txOutputsSorted = NE.toList
+            $ NE.sortBy (flip $ comparing coin) txOutputs
+
+    -- Step 2. (TO-DO or not) we need to check if the transaction outputs are not redeemable


what "redeemable" means here?

KtorZ · 2019-03-28T14:57:09Z

src/Cardano/Wallet/CoinSelection/LargestFirst.hs

+    when (utxoBalance < moneyRequested)
+        $ throwE $ UtxoExhausted utxoBalance moneyRequested
+
+    -- FIXME ? we need to check if the transaction outputs are not redeemable


I wondered yesterday already, but what "redeemable" means in this context?

there was a check in the legacy code https://github.com/input-output-hk/cardano-wallet-legacy/blob/develop/src/Cardano/Wallet/Kernel/CoinSelection/FromGeneric.hs#L292
Basically, checking if the address in transaction output is redeemable

Ah. Okay. I think we don't care here:

1/ We can't generate redeem address anyway
2/ If, through manual selection or whatever process we end up constructing a transaction to a redeem address, the node will reject it.

I am really not sure what's the rational is here 🤔 ...

removed unneeded comment

KtorZ · 2019-03-28T14:58:58Z

src/Cardano/Wallet/CoinSelection/LargestFirst.hs

+        $ throwE $ UtxoNotEnoughFragmented numberOfUtxoEntries numberOfTransactionOutputs
+
+    when (utxoBalance < moneyRequested)
+        $ throwE $ UtxoExhausted utxoBalance moneyRequested


I'd actually swap those two checks, such that, in case there's no UTxO available, it still returns a UTxOExhausted error (which we could rename to NotEnoughMoney basically? Don't you think? The utxo can be exhausted in two ways, as described in a comment, so perhaps, it's better to have this error reflecting this as well).

Also, I think that, those checks where done in the Nothing branch previously, such that they will only occur after the coin selection has been tried once. I think the rational was that successful calls to this function are more likely than error calls and thus, rather than doing those checks on every call, we simply do it in case of error and save some CPU cycles along the way.

swapped the errors, checked it in unit tests, and changed the name of the error

KtorZ · 2019-03-28T15:02:25Z

src/Cardano/Wallet/CoinSelection/LargestFirst.hs

+                (inp, out):utxo' = utxo
+                target' =
+                    (fromIntegral (getCoin (coin txout)))
+                    - (fromIntegral (getCoin (coin out)))


This seems wrong? The new target should be based on the current target and not on the initial one?

we have foldM atLeast utxos outputs and in the atLeast we process every output per go. And inside, we are looking which first coin from utxo (previously taken the biggest maxnumberofinputs of them and then taken from the smallest) can cover this target. To my best knowledge, the target within go (I changed inner loop that searches for this to pickTheFirst) my stay intact and the above expression does its job.

Hmmm... that isn't correct. The go may actually picks more than one UTxO (possibly depleting the whole list if there aren't enough to cover for the target), that's why it's an iterative approach.

The target starts being the txout's value. And then, after every pick, we makes it smaller by the amount of the corresponding UTxO entry we've picked, and iterate, until the target is covered. So, in the last branch, we should have:

targets' = target - fromIntegral (getCoin (coin out))

ok, finally got it - corrected the algorithm and included boundary and exemplary cases in unit tests to show the implementation is right now

KtorZ · 2019-03-28T15:03:45Z

test/unit/Cardano/Wallet/CoinSelection/LargestFirstSpec.hs

+        let check =
+                invariant "utxo must cover all transaction outputs"
+                (NE.length txOuts)
+                (\_ -> condCoinsCovering txOuts utxo)


You could use a precondition for this using QuickCheck's (==>)

KtorZ · 2019-03-28T15:21:22Z

test/unit/Cardano/Wallet/CoinSelection/LargestFirstSpec.hs

+        it "works as expected for zero-fee and not covered by utxo coin selection"
+            (property propLargestFirstNotCovered)
+        it "works as expected for zero-fee and fully covered by utxo coin selection when maximumNumberOfInputs is small"
+            (property propLargestFirstFullyCoveredSmallMaxInput)


I am a puzzled by the properties here 🤔 ? What properties are we actually looking for? I think you're mis-using property testing here. The testing logic is almost as complex as the implementation itself which is a good sign that tests are maybe doing too much. A good indicator is the way you can express the property in prose, what means "works as expected" here, if you're checking for a property, then you should be able to express it.

I'd suggest the following approach:

Reword these test cases into plain unit tests, where, given some inputs (that you can construct by hand, in a easy-to-read fashion), you obtain some expected output / behavior.

Add some property-based tests for actual properties of that largest first heuristic, for instance, I can see a few properties that I'd expect on such function:

forall (UTxO, NonEmpty TxOut), running largest first twice one the same UTxO yields exactly the same result

forall (UTXO, NonEmpty TxOut), for all selected input, there's no bigger input in the UTxO that is not already in the selected inputs.

forall (UTxO, NonEmpty TxOut), there's at least as many selected inputs as there are requested outputs

So in practice, the properties are very short to express, and it's really about performing the coin selection, and then, verifying that the output satisfies some conditions. All properties above assume that there are enough inputs to cover for all of the NonEmpty TxOut, so likely, they'll need preconditions (which could just be isRight $ runExceptT $ largestFirst ... ==> ...)

fair argument. Added unit tests already. Properties will be added in the next commit

this one is I do not understand : forall (UTXO, NonEmpty TxOut), for all selected input, there's no bigger input in the UTxO that is not already in the selected inputs.

algo goes : we take maxNumberOfInputs biggest utxo entries, and then take from the smallest to cover transaction outputs taking from the smallest. It seems, but I may be wrong, that it contradicts ^^^

I sticked to CoveringCase to run it quicker, as correct subset is significantly smaller to whole set of (Utxo, Empty TxOut) - that's my intuition to be verified

algo goes : we take maxNumberOfInputs biggest utxo entries,

Yes.

and then take from the smallest to cover transaction outputs taking from the smallest

No. We do cover biggest outputs first, and use the biggest inputs first to do so.

added the property. in the lights of correct implementation it makes sense

KtorZ · 2019-03-29T07:43:49Z

src/Cardano/Wallet/CoinSelection/LargestFirst.hs

+
+    -- FIXME ? we need to check if the transaction outputs are not redeemable
+
+    case foldM atLeast (L.reverse $ nLargest utxo, mempty) txOutputsSorted of


Why is the list reversed here 🤔 ?

we start to consume utxo from the smallest cut obtained by maximumNumberInputs (which takes those numbers of biggest utxos entries) . taken from : https://github.com/input-output-hk/cardano-wallet-legacy/blob/develop/src/Cardano/Wallet/Kernel/CoinSelection/FromGeneric.hs#L215

KtorZ · 2019-03-29T09:11:36Z

test/unit/Cardano/Wallet/CoinSelection/LargestFirstSpec.hs

+    -> NonEmpty Word64
+    -- ^ transaction outputs
+    -> Either CoinSelectionError [Word64]
+    -- ^ expecting CoinSelectionError or coins selected


Nice.
What about passing all the arguments above in a record type (instead of having comments here), so that at the call-site, it becomes even more readable ?

paweljakubas · 2019-03-29T15:26:13Z

src/Cardano/Wallet/CoinSelection/LargestFirst.hs

+atLeast (utxo0, selection) txout =
+    pickTheFirst (fromIntegral $ getCoin $ coin txout, mempty) utxo0
+    where
+    pickTheFirst


this should be called cover probably to better reflect intent

paweljakubas · 2019-03-29T15:36:24Z

test/unit/Cardano/Wallet/CoinSelection/LargestFirstSpec.hs

+            Map.toList (getUTxO utxo) L.\\ utxoEntriesInCoinSelection
+    let getExtremumValue f = f . map (getCoin . coin . snd)
+
+    if L.null utxo' then utxo' `shouldBe` utxo' else


is there Expectation that is "True"/expectationSatisfied? why this checking? sometimes utxo is completely depleted after coin selection and minimum from [] does not make sense...maybe secure min with default 0...

Hmmm.. since you're in a Monad, you could use when or unless here (from Control.Monad)

KtorZ

Good tests. I haven't yet re-reviewed the implementation, as I wanted to put the emphasizes on the tests first.
Some remarks on the form and coding style however.

KtorZ · 2019-03-29T16:13:13Z

test/unit/Cardano/Wallet/CoinSelection/LargestFirstSpec.hs

+                 100
+                 [10,10,17]
+                 (17 :| [])
+                 (Right [17])


😅 ... the suggestion of introducing a record type earlier was to use the named fields exactly here!

coinSelectionUnitTest UnitTestInput { maxNumOfInputs = 100 , utxoInputs = [10,10,17] , txOutputs = 10 :| [] , expectedResult = Right [17] }

This is where we get most of the readability (at the call-site) :)

indeed, corrected

KtorZ · 2019-03-29T16:15:03Z

test/unit/Cardano/Wallet/CoinSelection/LargestFirstSpec.hs

+                 [12,10,17]
+                 (1 :| [])
+                 (Right [17])
+                ))


What's the added value for this case compare to the previous one 🤔 ?

one is smaller than any input coin and the second is the biggest possible to cover by one input - it help me when checking algo impl

KtorZ · 2019-03-29T16:15:51Z

test/unit/Cardano/Wallet/CoinSelection/LargestFirstSpec.hs

+spec :: Spec
+spec = do
+    describe "Coin selection : LargestFirst algorithm unit tests" $ do
+        it "happy path result in successful selection - one input per output - a" $ do


I'd suggest to remove "happy path result in successful selection", and just keep the second part 👍

KtorZ · 2019-03-29T16:24:45Z

test/unit/Cardano/Wallet/CoinSelection/LargestFirstSpec.hs

+                 [1,2,10,6,5]
+                 (11 :| [1])
+                 (Left $ MaximumInputsReached 2)
+                ))


Good scenarios overall :+1

KtorZ · 2019-03-29T16:25:08Z

test/unit/Cardano/Wallet/CoinSelection/LargestFirstSpec.hs

+                 Properties and unit test generic scenario
+-------------------------------------------------------------------------------}
+
+data UnitTestInput = UnitTestInput


neat-picking but I'd just call that Fixture, because that's what it is.

KtorZ · 2019-03-29T16:48:52Z

test/unit/Cardano/Wallet/CoinSelection/LargestFirstSpec.hs

+            Map.toList (getUTxO utxo) L.\\ utxoEntriesInCoinSelection
+    let getExtremumValue f = f . map (getCoin . coin . snd)
+
+    if L.null utxo' then utxo' `shouldBe` utxo' else


Hmmm.. since you're in a Monad, you could use when or unless here (from Control.Monad)

test/unit/Cardano/Wallet/CoinSelection/LargestFirstSpec.hs

KtorZ · 2019-03-29T17:11:24Z

test/unit/Cardano/Wallet/CoinSelection/LargestFirstSpec.hs

+                     $ (Map.toList . getUTxO) utxo
+        rotate :: Int -> [a] -> [a]
+        rotate _ [] = []
+        rotate n xs = zipWith const (drop n (cycle xs)) xs


I'd suggest a different approach here to avoid having too much logic in the test:

change the precondition to something like isRight . runExceptT . largestFirst .... In the end, that's really what the pre-condition is about here, checking that we can perform the coin selection! So, let's just perform it and assume that it's right. On small sets of value, it should be fast enough to not be too slow to evaluate with quickcheck.

really do not know how to use properly isRight with runExceptT ... but when I use CoverCase then it is not need I bet...but drawback is that logic stays

KtorZ · 2019-03-29T17:12:03Z

test/unit/Cardano/Wallet/CoinSelection/LargestFirstSpec.hs

+
+instance Arbitrary CoveringCase where
+    arbitrary = do
+        n <- choose (1, 2)


perhaps slightly more than 2 ? What do you think ?

now (1,10) and works quickly

KtorZ · 2019-03-29T17:13:16Z

test/unit/Cardano/Wallet/CoinSelection/LargestFirstSpec.hs

+    arbitrary = do
+        n <- choose (1, 2)
+        txOutsNonEmpty <- NE.fromList <$> vectorOf n arbitrary
+        utxo <- arbitrary `suchThat` (condCoinsCovering txOutsNonEmpty)


Hmmm... we should have this either as a precondition or in the generator. Having it in both places is redundant. I'd be in favor of generating only valid CoveringCase, so checking only here once (previous comment about simplifying the precondition still applies though).

I like it to have in generator, but when I would know how to put isRight in the property precondition I would remove suchThat and condCoinsCovering code. On the other case, I would need to make sure significant number of covering cases are tried => checkCoverage to be used

paweljakubas · 2019-03-30T18:33:47Z

src/Cardano/Wallet/CoinSelection/LargestFirst.hs

+            throwE $ MaximumInputsReached (fromIntegral n)
+
+
+-- Selecting coins to cover at least the specified value


Added this extensive comment how the largestFirst works - hope it will save time anyone trying to understand this algorithm. This along with tests should explain the matter in a comprehensible way

KtorZ · 2019-04-01T08:21:21Z

src/Cardano/Wallet/CoinSelection/LargestFirst.hs

+--     UTxO input, not participating in the coverage, is taken. We are back at (b)
+--     step as a result
+--
+-- The steps are continued until all transaction are covered.


Nice :)

I'd even add either, before (c) or at the end of (b) that, each output is treated independently wit the heuristic described in (c).

KtorZ · 2019-04-01T08:22:49Z

src/Cardano/Wallet/CoinSelection/LargestFirst.hs

+--      which coin selection will be tried
+-- (c) the biggest candidate UTxO input is tried first to cover the transaction
+--     output. If the input is not enough, then the next biggest one is added
+--     to check if they can cover the transaction output. This process id continued


id continued -> is continued

KtorZ · 2019-04-01T08:28:15Z

test/unit/Cardano/Wallet/CoinSelection/LargestFirstSpec.hs

+        Left err ->
+            result `shouldBe` (Left err)
+        Right expectedCoinsSel ->
+            result `shouldBe` (return expectedCoinsSel)


The 5 lines above are strictly equivalent to

result `shouldBe`expected

The pattern-match is superfluous here.

KtorZ · 2019-04-01T08:38:32Z

src/Cardano/Wallet/CoinSelection/LargestFirst.hs

+
+-- | Largest-first input selection policy
+largestFirst
+    :: forall m. MonadIO m


IO isn't needed here, the constraint is too strong and I'd suggest to lower it down to Monad m

KtorZ · 2019-04-01T08:56:31Z

src/Cardano/Wallet/CoinSelection/LargestFirst.hs

+
+-- | Largest-first input selection policy
+largestFirst
+    :: forall m. Monad m


There was no need for a MonadIO m => constraint here (was actually too strong), so I've replaced it with a Monad m =>

KtorZ · 2019-04-01T08:57:25Z

src/Cardano/Wallet/CoinSelection/LargestFirst.hs

+        $ throwE $ NotEnoughMoney utxoBalance moneyRequested
+
+    when (numberOfUtxoEntries < numberOfTransactionOutputs)
+        $ throwE $ UtxoNotEnoughFragmented numberOfUtxoEntries numberOfTransactionOutputs


I'd move these (+ the corresponding local declarations above) into the Nothing -> branch, to avoid computing them on every run, but only when the selection failed.

KtorZ · 2019-04-01T09:03:48Z

src/Cardano/Wallet/CoinSelection/LargestFirst.hs

+                target' =
+                    target - (fromIntegral (getCoin (coin out)))
+            in
+                coverOutput (target', ins ++ [(inp, out)]) utxo'


In general, I'd suggest to always prepend elements to lists when using recursion with a list accumulator, and in the terminal case, reverse the list. Because built-in lists in Haskell are linked-list, adding elements to the end of a list is costly, while prepending elements is O(1). Here, it probably doesn't matter much because inputs will remain rather small in practice; but still 😶

done, and also updated tests for it

KtorZ · 2019-04-01T09:05:02Z

test/unit/Cardano/Wallet/CoinSelection/LargestFirstSpec.hs

+    let opts = defaultCoinSelectionOptions 100
+    let resultOne = runIdentity $ runExceptT $ largestFirst opts utxo txOuts
+    let resultTwo = runIdentity $ runExceptT $ largestFirst opts utxo txOuts
+    resultOne === resultTwo


changed here the usage of MonadIO + shouldBe with just === & runIdentity; there's no need for full IO :)

KtorZ · 2019-04-01T09:05:12Z

test/unit/Cardano/Wallet/CoinSelection/LargestFirstSpec.hs

+    :: CoveringCase
+    -> Property
+propAtLeast (CoveringCase (utxo, txOuts)) =
+    isRight selection ==> let Right s = selection in prop s


So here I've required that selection is Right as a precondition because our property only matters for valid selections.

beautiful 💯

[92] move to Cardano.Wallet.* [92] Comply with review [92] Use Quantity [92] Remove random and remove other undefined

[92] Compile fix

- Less intermediate types - Rely on built-in function on list instead of custom function for performances (O(n*log(n)) instead of (O(n)) - Correct reporting of errors

…tests

…aning just small correction complying with review

paweljakubas requested review from Anviking and KtorZ March 25, 2019 16:25

paweljakubas self-assigned this Mar 25, 2019

paweljakubas added this to the Submit Transactions milestone Mar 25, 2019

paweljakubas force-pushed the paweljakubas/92/adding-types branch 2 times, most recently from e6b4d5a to 81e955f Compare March 25, 2019 16:51

Anviking reviewed Mar 25, 2019

View reviewed changes

src/Cardano/Wallet/CoinSelection.hs Outdated Show resolved Hide resolved

src/Cardano/Wallet/CoinSelection.hs Outdated Show resolved Hide resolved

KtorZ suggested changes Mar 25, 2019

View reviewed changes

paweljakubas force-pushed the paweljakubas/92/adding-types branch from 81e955f to 9605cdd Compare March 25, 2019 20:09

paweljakubas requested a review from KtorZ March 25, 2019 20:13

paweljakubas force-pushed the paweljakubas/92/adding-types branch from 9605cdd to 6214de3 Compare March 26, 2019 08:14

akegalj reviewed Mar 26, 2019

View reviewed changes

paweljakubas force-pushed the paweljakubas/92/adding-types branch 2 times, most recently from 7591d95 to 7e7514b Compare March 27, 2019 13:32

paweljakubas changed the title ~~Add types skeleton of coin selection and fee calculation~~ Add types skeleton of coin selection and largestFirst algo implementation Mar 27, 2019

paweljakubas force-pushed the paweljakubas/92/adding-types branch from 6a7e7c8 to 892f3ea Compare March 27, 2019 19:01

paweljakubas force-pushed the paweljakubas/92/adding-types branch from 892f3ea to b4db42a Compare March 28, 2019 11:22

KtorZ suggested changes Mar 28, 2019

View reviewed changes

KtorZ reviewed Mar 29, 2019

View reviewed changes

paweljakubas force-pushed the paweljakubas/92/adding-types branch from 769eb8d to 21e226e Compare March 29, 2019 15:12

paweljakubas commented Mar 29, 2019

View reviewed changes

paweljakubas force-pushed the paweljakubas/92/adding-types branch from 21e226e to 75b761c Compare March 29, 2019 15:32

paweljakubas requested a review from KtorZ March 29, 2019 15:33

paweljakubas commented Mar 29, 2019

View reviewed changes

KtorZ suggested changes Mar 29, 2019

View reviewed changes

paweljakubas force-pushed the paweljakubas/92/adding-types branch from 75b761c to 83a3d4f Compare March 30, 2019 18:25

paweljakubas commented Mar 30, 2019

View reviewed changes

paweljakubas requested a review from KtorZ March 30, 2019 18:38

KtorZ force-pushed the paweljakubas/92/adding-types branch from 04ea9bc to 893002b Compare April 1, 2019 08:55

KtorZ approved these changes Apr 1, 2019

View reviewed changes

paweljakubas and others added 11 commits April 1, 2019 12:40

[92] Add types skeleton and functions to support in the next steps

f6d666b

[92] move to Cardano.Wallet.* [92] Comply with review [92] Use Quantity [92] Remove random and remove other undefined

[92] First largestFirst implementation

9d345a8

[92] Compile fix

simplify coin selection implementation

03675ef

- Less intermediate types - Rely on built-in function on list instead of custom function for performances (O(n*log(n)) instead of (O(n)) - Correct reporting of errors

[92] adding coin selection unit tests

cae5237

fix largest first errors, add UtxoNotEnoughFragmented and improve on …

62e4350

…tests

Adding test for small MaximumNumberOfInputs

f0a29ec

Adding unit tests and changing to NotEnoughMoney

6df812e

Correcting properties

0d832c5

Correct largestFirst, add property and number of tests. Plus code cle…

e8db3f4

…aning just small correction complying with review

simplify pre-conditions for properties in CoinSelection

96ea9a8

Final cleanup and improvements

1934d44

paweljakubas force-pushed the paweljakubas/92/adding-types branch from 893002b to 1934d44 Compare April 1, 2019 10:40

KtorZ merged commit 82fa37c into master Apr 1, 2019

KtorZ deleted the paweljakubas/92/adding-types branch April 1, 2019 16:01

KtorZ mentioned this pull request Apr 2, 2019

Port coin selection and fee calculation from legacy #92

Closed

7 tasks


		-- FIXME ? we need to check if the transaction outputs are not redeemable

		case foldM atLeast (L.reverse $ nLargest utxo, mempty) txOutputsSorted of

		throwE $ MaximumInputsReached (fromIntegral n)


		-- Selecting coins to cover at least the specified value

Add types skeleton of coin selection and largestFirst algo implementation #121

Add types skeleton of coin selection and largestFirst algo implementation #121

Conversation

paweljakubas commented Mar 25, 2019

Issue Number

Overview

Comments

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

paweljakubas commented Mar 27, 2019

KtorZ left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

paweljakubas Mar 29, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

paweljakubas Mar 29, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KtorZ left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

paweljakubas Mar 30, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

paweljakubas Mar 30, 2019 • edited Loading

Choose a reason for hiding this comment

paweljakubas Mar 30, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

paweljakubas Mar 29, 2019 •

edited

Loading

paweljakubas Mar 29, 2019 •

edited

Loading

paweljakubas Mar 30, 2019 •

edited

Loading

paweljakubas Mar 30, 2019 •

edited

Loading

paweljakubas Mar 30, 2019 •

edited

Loading