Update tutorial code

Signed-off-by: Matthias Geihs <matthias@perun.network>

source/go-perun/tutorial/channels/closing.rst

@@ -59,14 +59,14 @@ We therefore just need to *register* and *settle* which looks like this:
 
 .. literalinclude:: ../../../perun-examples/simple-client/node.go
    :language: go
-   :lines: 130-147
+   :lines: 139-156
 
 The other participant would then have its `AdjudicatorEvent` handler called with a
 `ConcludedEvent`_ and should then also execute `closeChannel`.
 
 .. literalinclude:: ../../../perun-examples/simple-client/node.go
    :language: go
-   :lines: 149-155
+   :lines: 158-164
 
 .. _IsFinal: https://pkg.go.dev/perun.network/go-perun/channel#State
 .. _channel.Settle: https://pkg.go.dev/perun.network/go-perun/client#Channel.Settle

source/go-perun/tutorial/channels/opening.rst

@@ -9,7 +9,7 @@ It looks like this:
 
 .. literalinclude:: ../../../perun-examples/simple-client/node.go
    :language: go
-   :lines: 38-68
+   :lines: 48-78
 
 The `ProposeChannel` call blocks until *Alice* either accepted or rejected the channel
 and funded it.
@@ -26,7 +26,7 @@ An example Proposal handler looks like this:
 
 .. literalinclude:: ../../../perun-examples/simple-client/node.go
    :language: go
-   :lines: 70-89
+   :lines: 80-99
 
 You can add additional check logic here but in our simple use case we always accept
 incoming proposals. After the channel is open, both participants will have their `NewChannel` callback called.
@@ -41,7 +41,7 @@ time-intensive tasks. You should also start the :ref:`watcher <the-watcher>` as
 
 .. literalinclude:: ../../../perun-examples/simple-client/node.go
    :language: go
-   :lines: 91-100
+   :lines: 101-110
 
 .. note::
 

source/go-perun/tutorial/channels/updating.rst

@@ -8,7 +8,7 @@ We now give the `node` an `updateChannel` function to update the channel by send
 
 .. literalinclude:: ../../../perun-examples/simple-client/node.go
    :language: go
-   :lines: 102-115
+   :lines: 111-124
    :emphasize-lines: 8,9
 
 In the highlighted lines you can see that we use index `0` for the `Balances` slice.
@@ -28,7 +28,7 @@ This example function accepts all updates:
 
 .. literalinclude:: ../../../perun-examples/simple-client/node.go
    :language: go
-   :lines: 117-124
+   :lines: 126-133
 
 An update can also be rejected with a reason. This starts the :ref:`dispute process <disputes>`.
 

source/go-perun/tutorial/setup/chain.rst

@@ -8,7 +8,7 @@ The `ContractBackend` is constructed from the `ethclient.Client` in combination
 
 .. literalinclude:: ../../../perun-examples/simple-client/onchain.go
    :language: go
-   :lines: 19-27
+   :lines: 29-36
 
 .. note::
    | You can dial any RPC Ethereum node here, even an *Infura* endpoint.

source/go-perun/tutorial/setup/config.rst

@@ -10,20 +10,20 @@ hold the configuration:
 
 .. literalinclude:: ../../../perun-examples/simple-client/config.go
    :language: go
-   :lines: 15-23
+   :lines: 25-33
 
 *Alice* and *Bob* both get a `Role` to define behavior that is specific to them.
 This will be used to decide which side of the protocol to execute.
 
 .. literalinclude:: ../../../perun-examples/simple-client/config.go
    :language: go
-   :lines: 25-40
+   :lines: 35-50
 
 Then we need an `init` function that will set all fields of the configuration on startup:
 
 .. literalinclude:: ../../../perun-examples/simple-client/config.go
    :language: go
-   :lines: 42-
+   :lines: 52-
 
 The on-chain addresses can be hard-coded here since we already know them from the
 *ganache-cli* setup.

source/go-perun/tutorial/setup/contracts.rst

@@ -38,7 +38,7 @@ First we have to deploy the *Adjudicator* and then use the *Adjudicator's* addre
 
 .. literalinclude:: ../../../perun-examples/simple-client/onchain.go
    :language: go
-   :lines: 28-40
+   :lines: 38-50
 
 The context is needed to specify how long *go-perun* will wait for both deployments to succeed.
 If you have set a higher block time in *ganache*, you need to increase the timeout here too.
@@ -61,7 +61,7 @@ We wrap it in a function that accepts a *ContractBackend* and the addresses of t
 
 .. literalinclude:: ../../../perun-examples/simple-client/onchain.go
    :language: go
-   :lines: 42-47
+   :lines: 52-57
 
 Putting it together
 -------------------
@@ -71,7 +71,7 @@ is running:
 
 .. literalinclude:: ../../../perun-examples/simple-client/onchain.go
    :language: go
-   :lines: 49-65
+   :lines: 59-75
 
 The addresses for `Adjudicator` and `AssetHolder` can be hard-coded again since we know
 what they will be when we deploy the contracts for the first time. This implies that

source/go-perun/tutorial/setup/funding.rst

@@ -9,7 +9,7 @@ deposited is agreed upon by both participants.
 
 .. literalinclude:: ../../../perun-examples/simple-client/channel.go
    :language: go
-   :lines: 22-27
+   :lines: 32-37
 
 As you can see we use an `ETHDepositor` which means that the channel will only be funded with *Ether*.
 There is an equivalent `ERC20Depositor` if you need *ERC20 Tokens*.

source/go-perun/tutorial/setup/node.rst

@@ -8,7 +8,7 @@ To manage all state we will create a `node` struct:
 
 .. literalinclude:: ../../../perun-examples/simple-client/node.go
    :language: go
-   :lines: 24-36
+   :lines: 34-46
 
 It is named `node` to not be mixed up with a *go-perun* `Client`.
 
@@ -25,27 +25,27 @@ on whether he wants to open that channel.
 
 .. literalinclude:: ../../../perun-examples/simple-client/node.go
    :language: go
-   :lines: 70
+   :lines: 80
 
 The `Update` callback queries the user whether he wants to accept the channel update
 that was proposed to him.
 
 .. literalinclude:: ../../../perun-examples/simple-client/node.go
    :language: go
-   :lines: 117
+   :lines: 126
 
 `NewChannel` is used whenever a new channel was successfully opened.
 
 .. literalinclude:: ../../../perun-examples/simple-client/node.go
    :language: go
-   :lines: 91
+   :lines: 101
 
 `AdjudicatorEvent` is called when the `watcher` received an on-chain event from the
 `Adjudicator`. This will be relevant for closing a channel and handling disputes.
 
 .. literalinclude:: ../../../perun-examples/simple-client/node.go
    :language: go
-   :lines: 149
+   :lines: 158
 
 .. _client.New: https://pkg.go.dev/perun.network/go-perun/client#New
 .. _ProposalHandler: https://pkg.go.dev/perun.network/go-perun/client#ProposalHandler

source/go-perun/tutorial/setup/wallet.rst

@@ -16,7 +16,7 @@ To structure our program, we introduce a *setupWallet* function that will do the
 
 .. literalinclude:: ../../../perun-examples/simple-client/wallet.go
    :language: go
-   :lines: 16-33
+   :lines: 26-43
 
 We pass the *role* to the function since we need to create one account for each *role*.
 The third argument to `NewWallet`_ defines the index of the first account that will be later on created with `NewAccount`_. *Alice* will have the first account (index 0) and *Bob* the second (index 1).
@@ -42,7 +42,7 @@ We will need this `Transactor` in the next step:
 
 .. literalinclude:: ../../../perun-examples/simple-client/wallet.go
    :language: go
-   :lines: 35-39
+   :lines: 45-49
 
 .. note::
    | A signature is only valid on a blockchain with the same *chain id*.

source/go-perun/tutorial/together.rst

@@ -6,11 +6,11 @@ It will be called once for *Alice* and once for *Bob* from *main* like this:
 
 .. literalinclude:: ../../perun-examples/simple-client/main.go
    :language: go
-   :lines: 14-34
+   :lines: 23-41
 
 .. literalinclude:: ../../perun-examples/simple-client/main.go
    :language: go
-   :lines: 35-
+   :lines: 43-82
 
 .. _run-the-app: