Viktor :
a swear is a case state transition automata, where at each stage of the litigation, a witness contract is called with the same ABI: testimonyFor(status, serviceId, clientAddress) -> newstatus
and it is this contracts specific methods which you need to call to submit the evidence
this givesa a superclean and superlean swear abstraction.
Oren:
I like the idea.
so in the basic “mirror” game there will be two 2 expert witnesses .
First one , which validate and confirm the client subscription to the service by validate the service promise ,lets call it “SubscriptionWitness”.
It introduce an abi for clients to submit a “promise” as an evident.
Second , which check the actual mirroring staff by resolving both enss and compare them ,lets call it “MirrorWitness” .
For the case of the “mirror” game the client do not need to submit any evident because it the enss addresses are hard coded in the contract.
So the swear contract will call SubscriptionWitness.testimoryFor(status, serviceId, clientAddress) and if the status is OK it will call “MirrorWitness.testimoryFor(status, serviceId, clientAddress) ” and take decision according to that..
Further abstraction can be done by having the passing the swear contrat a list of witnesses contract addresses , so it then can iterate through each :
e.g
for (i=0;i<numberOfWitnesses;i++)
{
status = witness[i].testimoryFor(status, serviceId, clientAddress)
if status != STATUS_OK{
return status
}
}
return status

Related to the discussion at SwarmResearch.
This issue removes anything related to waivers and means a simplification on both the smart-contract side as well as the side that implements the chequebook smart-contract.

Proposal: keep beneficiary, rename owner to issuer

By always submitting the note (in cashNote and submitPaidInvoice) the storage footprint (and hence gas cost) could be drastically reduced.

A first attempt at this can be found in #13

AvailableBalance is used on the go-side to calculate the balance against which cheques can be written without risking a ChequeBounced event.

As discussed during a roundtable we should look into automatically generating go binding here using CI so it can be used on the go side as a vendored dependency.

The parameter timeout is confusing. At some places, it is used as an absolute point after which something can happen. At some places, timeout means a relative time (now + timeout) after which something can happen.
I propose to stick to timeout for the relative time, but consider a different name for the absolute time.

Upgrading to the newest version of openzeppelin Solidity breaks the smart-contract when deployed on Ganache.
Reason: Ganache does not inject the correct value for v. (0 or 1, instead of 27 or 28).

Current solution in place: Use openzepplinSolidity version: 2.1.2
Desired solution: make the repository compatible with the newest version of openzeppelin solidity.

Most likely needs an adjustment to SimpleSwap.

1. Make chequebook ERC20-compatible
2. Adapt ABIGEN script / CI script en push go-bindings to a different repo
3. Make Swarm source-code work with ERC20 compatible go-bindings

// promise represents a promise from a service to serve client(beneficial) up to a certain blockNumber
type Promise struct {
Contract common.Address // address of swearGame contract, needed to avoid cross-contract submission
Beneficiary common.Address // address of Beneficiary (client)
BlockNumber *big.Int // Until which block number this promise is valid
Sig []byte // signature Sign(Keccak256(contract, beneficiary, blocknumber), prvKey)
}

Description

Currently the build/CI process automatically creates a separate folder for a new version of the S/S/S contracts.

Use a go module with a major version update for a more idiomatic way to reference the generated code.

Make constructor payable and submit deposit if msg.value != 0

Running yarn compile will show warning messages, warning that there are no license headers. Resolve this and add appropriate license headers (similar license as our bee repo).

Hi, in the documentation this address: 0xA6B88705036F2a56807af157c116b7dfCDabf968 is said to be the default factory using this token address: 0xe1927106821DB21c8657B8EB483705E95903eE93

But the bee clients are currently setting this address: 0xf0277CAFfea72734853B834AFC9892461eA18474 as the default factory contract and this address 0x2aC3c1d3e24b45c6C310534Bc2Dd84B5ed576335 as the token contract.

Here is the bee code that set the factory: https://github.com/ethersphere/bee/blob/master/pkg/settlement/swap/chequebook/factory.go#L172

Which one is the correct? If is the latter, could you also validate the contract code in etherscan? https://goerli.etherscan.io/address/0x2ac3c1d3e24b45c6c310534bc2dd84b5ed576335#code

Design how the smart contracts need to be deployed (which testnet, configuration needed, etc.).

Setup / share tools for deployment and document.

Deploy to testnet.

When reviewing the SimpleSwap.sol code with @holisticode , we came up with a potential vulnerability of SimpleSwap. If exploited, an attacker can lock the funds of the checkbook owner for a given period (equal to the hardDeposit timeout), resulting in the checkbook owner not being able to economically engage with other nodes for this period.

Assuming:

• Harddeposits are the only way to guarantee solvency of the checkbook for a node
• A node requires solvency of a checkbook to in order to engage in the SWAP protocol (start delivering chunks back and forth)*

Then:
For a honest node who expects to receive a check (A) and does not want a profit that approaches zero, this node first wants to see a hard-deposit guaranteed for him in the checkbook of a peer (B).
As B wants to start using SWARM, he has to commit himself to funding set a hard deposit aside for at least one (but probably multiple peers).

Attack:
Evil node C tricks B into believing that he/she needs a hard-deposit. C can have multiple nodes and the cumulative hard-deposits to all C's can be sufficiently high such that B cannot engage in Swarm anymore without the expected service of C, without topping up again. When this point is reached (can be a very little time if C sets up the attack well), C can stop providing services for B and B has to wait for a period equal to the hardDepositTimeout until she can engage again in SWAP with other nodes. This circle can repeat ad-infinitum.

Consequence:
The attack can disrupt the usability of SWARM for B as it will diminish the resources that B has available from his deposit to spend on rewarding honest nodes at any given time.

*If there is no solvency guarantee, a node should always expect a bankrun on the checkbook of the peer as there is no way of knowing about other outstanding checks. Therefore, once a node has a cheque that is worth a positive sum of money, he should immediately cash out this cheque. A cheques worth is the cumulative value of the check - the gas costs of the cheque. We expect the worth to be negative initially and when the worth is marginally above zero it should be cashed out due to the logic above.

To make Swap more accessible to outsiders, we could set up a simple web-app which shows what Swap does.

submitChequeLower supposedly can do everything which submitCheque can do as well. For code clarity, we can drop submitCheque and rename submitChequeLower to submitCheque.

We have to gather sufficient reasoning on the safety of dropping this function (no party should be able to game the other party), as well as a gas-cost analysis.

Review the order or functions / parameter declarations and general style of the SimpleSwap.sol

see #15 for early experiments

Currently hard deposits can be decreased to 0 after 2 days which breaks all attempts at offchain swear.

The cheque logic is currently completely separate from the notes logic. Notes also can be used for simple cheques (only value, beneficiary fields), but unlike cheques these notes cannot be replaced with higher index notes.

The cheque-specific logic could probably be dropped if #11 is implemented.

Currently the index field is only used as a kind of nonce. There might be a way to have a replacement mechanism similar to cheques, although it is not yet clear how this would work in detail.

Currently, we name the person receiving payment during submitCheque the beneficiaryAgent, whereas the beneficiary (Externally owned account) is the beneficiaryPrincipal. This might not be the best naming, let's think about it.

Master will be for now for simpleSwap.sol + tests.
We create a branch "experimental" where we put all experimental code for the SW3 suite. When one feature is sufficiently tested and stable, we merge this feature from experimental to master.

Refactoring by using helper functions

Related EIP: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-712.md

Update the README.md of this directory to reflect the current state of the smart-contracts

open question: who is authorized?

offchain and onchain use the same fields differently
not every field might be necessary

Order of parameters in function cheqeuHash does not match the order of these parameters in the keccak256 hash.
Proposal: change the order of parameters in the function or change the order of parameters in the keccak256 hash in the body of this function.

  public pure returns (bytes32) {
    return keccak256(abi.encodePacked(swap, serial, beneficiary, amount, timeout));
  }```

If there is a cash-out in between the prepareDecreaseHardDeposit and decreaseHardDeposit, the line
hardDeposit.amount = hardDeposit.amount.sub(hardDeposit.decreaseAmount); in decreaseHardDeposit might throw and decreasing the hardDeposit can be effectively blocked temporarily.
Proposed solution: if decreaseAmount is more than amount, set the hardDeposits to 0.
As an extra benefit: this makes the require(decreaseAmount <= hardDeposit.amount) in prepareDecreaseHardDeposit redundant.
@ralph-pichler

The Swarm codebase has a need for a global paidOut call. Without this call, calculating availableBalance on the go-side requires a paidOut(peer) call for every peer and historical peer to the chequebook, which might grow to a substantial size when Swarm is longer-running.

Currently, SimpleSwap.sol requires only that a cheque has an increasing serial number. If nodes just randomly increment the serial of every cheque with a number, the MAX_UINT of Solidity can be reached quickly and a cheque cannot be updated anymore, only cashed out.

The node's software should not sign cheques with a serial that is increasing with more than one from the last known cheque of this node.
@holisticode , where should we document such details?

The _computePayout function could be structured more simply.

Documentation should be revisited and updated/added where needed

Problem: The current SWEAR design seems like it could be simplified. When I was reading through the orange papers, I came up with a design for a SWEAR deposit system (the name may be incorrect) that could look like this. With this design you can keep deposits moving through indefinitely and attach other modules that rely on information regarding deposits to different nodes. Keep in mind this is just an abstract sketch.

pragma solidity >= 0.4.13;

contract SWEAR {
    
    uint swarmEpoch = 3 days;
    
    mapping(address=>Deposit) public deposits;
    
    struct Deposit {
        bool inDepositPeriod;
        uint vestingPeriod;
        uint depositedAmount;
    }
    
    function() {
        revert();
    }
    
    function register(uint epochs) payable returns (bool) {
        if (!deposits[msg.sender].inDepositPeriod) {
            deposits[msg.sender] = Deposit({inDepositPeriod: true, vestingPeriod: now + epochs * swarmEpoch, depositedAmount: msg.value});
            return true;
        }
        if (msg.value > 0) { revert(); }
        // can't reregister, return false telling node that it cannot alter its deposit
        return false;
    }
    
    function collectDeposit() external returns (bool) {
        Deposit storage depositInfo = deposits[msg.sender];
        if (depositInfo.inDepositPeriod && depositInfo.vestingPeriod <= now) {
            uint toTransfer = depositInfo.depositedAmount;
            deposits[msg.sender] = Deposit(false, 0, 0);
            msg.sender.transfer(toTransfer);
            return true;
        }
        return false;
    }
}