# Research Open Hours - Agenda

## July 9
- Light node proposal
Links:
Dan Nickless5:05 PM
https://github.com/ethereum/web3.js/issues/2739
Dan Nickless5:08 PM
https://ipfsdrop.com/offcial/ipfs/js-ipfs-0-24-0-released/
Vojtech Simetka5:09 PM
libp2p.io/implementations/
Dan Nickless5:10 PM
https://webtorrent.io/
Dan Nickless5:12 PM

## June 4
- presentation on the BZZ token and incentives (Dani, Rinke)

## April 9
- (Rinke & Janos): Multiple overlay / multiple Kademlia Swarm. See discussion this morning (9 april) in the #core channel of Beehive
-
## March 26
- (Racin - Vero) Update on latest research in Entanglement
- Snarl: Optional Add-on for entangling data in Swarm

## March 12
- ~~(Rinke) RECC (Register, Earn, Cashout, Challenge => Alternative to postage lottery for positive incentivization for storage)~~

## February 27
- (Viktor) Help needed with book and diagrams

## February 20
Agenda:
- (viktor-rinke) bandwidth compensation:
- forwarder reward = storer reward
- simplify pushsync incentives

## February 13
Agenda:
- Incentivised network IDs https://github.com/ethersphere/user-stories/issues/63
- SWAOP only network https://github.com/ethersphere/user-stories/issues/64
## February 6
Agenda:
- zero-eth entry into Swarm, with token payments
- Asking another person to cash out cheques (already provided by the chequebook as an option).
- Let the beneficiary of this cash-out not be the person who receives this token, but let it be the bonding-curve contract
- Bonding-curve contract can pay out Ether to the the beneficiary
- Write up Dani about token model: [here](https://gist.github.com/nagydani/d5c09c331224bfbffbcbe28b347ceb8e)

## January 30
Agenda:
- Swarm token funding model.
- Proposal to use [Aragon](https://fundraising.aragon.black/)
- [Tax on profits](https://github.com/ethersphere/swap-swear-and-swindle/pull/102)
- [Aragon application form questions](https://hackmd.io/BgFT1zOMRc-8UePkdjAySg)
- Elad Verbin wrote up something about Bonding Curves. Daniel will verify wether we can share it.

## January 23

- Debt cheques: https://github.com/ethersphere/swarm/pull/1983
Proposal Rinke: https://github.com/ethersphere/swarm/pull/1983#issuecomment-577362381

When we receive a cheque, we adjust the balance we have with our peer with the worth of the cheque. In normal situations, the resulting balance should be zero, however, due to network asynchronities, it might happen that the resulting balance is not exactly zero. That is why, we must allow for *some* difference of the new balance with 0. There is an upper boundary to this adjustment (to prevent the described attack in the issue), which is set to a fraction of the payment threshold (or worth of the cheque).

## january 16
- new design for postage stamp, garbage collection and lottery

Without postage, there is only a weak incentivization to forward chunks to it's neighborhood.

Also, without postage we can spam the Swarm network.

One-time cost is attached to uploaded chunk, to make upload costly. This one time cost can be burned (but we can also use it as a revenue for those who credibly store it).

What is a postage stamp? Verifiable reference to a payment + a reference to a chunk + signature.

What properties does the payment need to have:
- we can't have one payment per chunk => must be grouped.
- The numbers of chunk that we associate with a payment must be verifiable based on local information.

How to do this:
Postage stamp is in batches. The batch has the following restriction:
Any two addresses/chunks that below to the same batch, must not share more than x bits in their prefix (prefix collission constraint).

With this restriction, there is an upper limit to the amount of chunks per batch.

If there is a collision, nodes will see such collisions (given depth of batch is more than log(N), where N is the amount of nodes in the network) as the chunks with a collision will be sent to the same neighborhood. Punishment: one of the two chunks is not kept.

How to fill batches:
- By random (luck), taking several badges and just put the chunks in fitting collision chunks.
- By mining the (encrypted) chunks to fit the batch.

When you buy a batch, you can buy several. The smart-contract has an variable that holds the batch-depth (which should be more than the depth of Swarm).

Value of postage stamp is the per-chunk balance

Storer nodes rank the chunks based on the value of the postage stamps and delete the lowest value of quantile.
Question for Victor: how do we mingle together profit estimations of postage with profit estimations of SWAP?

Lottery:
Automated raffle, every N blocks.
Block hash is global draw.
Registered nodes that are closest to this hash can apply to winning the lottery

Close nodes apply to winning the lottery by submitting their minimum price.
Now, seconds random number will generate a few random sample batches. Applicant nodes need to submit proofs of custody of all chunks that belong to their batch, got sampled, falls in their area of responsibility, and is not garbage collected (based on garbage collection strategy based on postage price).

## January 9
- (Vik) research office hours moved today to 4pm CET bc of other commitments
- (Vik) new design for postage lottery
- needs to be written up first
- (Vik) Rinke and Dani's results on the honey token
- Multiple arguments for using our own ERC20 "Honey" tken:
- Fluctuations in price are linked to Swarm not to the whole ekosystem as with ETH
- Easier bridging
- How can the token come to existence
- Premining (allows us to allocate as well e.g. 60% swarm foundation, 20% partners...)
- Deposit-based way (there should be a SC that dispenses tokens - could be similar to the [oasis web](https://oasis.app/) UX)
- with a bonding curve, the capital isn't as available as in the case of pre-mining

### Contract state on Swarm
- Binary merkle trie
- Idea comes from Elad -- Merkle proof on steriods (Praque)
- a solidity library would need to be written
- Write up on EthResearch

## December 19
- (Rinke) Low balance mode https://github.com/ethersphere/swarm/issues/1996
- Follow up on trojan chunk
-
## December 5
- User Experience for postage stamp
If you want to upload something, you need to pay some money which is proportional to the upload you do. There should be some possibility to make a low, medium, or high priced upload, meaning that your chunk will stay longer in the network.
- Viktor: Pay before uploading
- Pay upfront for a certain data amount e.g. by the GB
- Decision: collect user stories (everyone who can think of one should write it) and discuss them on next call
## November 28
Victor wants to share 3 ideas:
- Pricing
- Scenario: node feels price pressure (in a certain bin all peers raise the price). You want to see wether the particular peers in this bin are expensive, or want to conspire against you.
- If peers in a particular bin raise prices, default reaction is to raise price yourself, but you might price yourself out of the market.
- You can circumvent this by passing the chunk not to the peer who is closest to the chunk, by passing it to a peer that is closer to the chunk, but further away than the original peer (e.g. pass it to a peer in bin 1, instead of bin 0).
- Response Dani: premature optimizing, but argument in favor of protocol that it allows such strategies.

- Messaging (key exchange with feeds)
- Recap anonymous chat:
- If you know the public key of your peers, you can have one single, universal chat scheme where you can generate an outbox and read the other's outbox.
- You can send a chunk to the closest node which is your destination.
- Any chunk that I receive and that is in my neighborhood, I chop the first 32 bytes and decrypt the rest of the chunk with my the corresponding private key of Public Key, the first 32 bytes serve as an entropy. Sending party has to mine this chunk, in order to find a chunk that is close enough to the receiver.
- Postage stamp makes sure the chunk is not garbage collected, other nodes will not know a chunk is actually a message, when receiving node comes online he will receive chunk if the chunk is still available.
- Because of the specifics of postage stamps, a targeted chunk to a specific neighborhood will be estimated to have less postage stamp attached than a batch of chunks which is randomly distributed in the network.

- Pinning
- We spoke about the missing chunk notification protocol.
-

## November 7
### Agenda
* ERC20 support in the chequebook. Only ERC20, or ERC20/native?

## October 31
Overvation incentive structure
Completely figured out the incentivization of download requests
Pretty far with regards to incentivization of upload (push sync)
It seems like incentivizing PSS is hard
Start with unincentivized PSS (PSS can function as best-effor service, old style spam prevention)
Concluded that push sync cannot be done over PSS
Major realization:
We cannot direclty charge for requests (charge for delivery only)
For delivery we charge a part of the fee as decreasing function of proximity (if attacker controls two nodes, they can spam the network by requesting chunks which are generated by the other node).
If postage stamps which chunks were uploaded is also attached to download, we can incentivize decentralized forgetting (not part of 1.0)
Direct roadmap:
speccing out the retrieval part very soon
If a node responds with a chunk to a request, SWAP payment was incured, amount which you pay depends on the distance between servicing peer from the chunk --payment will be distributed along the path
Disconnect from nodes who are regularly disconnecting
Should be some function for payment for delivery diminishes for distance

## October 24
- Bad SWAP peers
- Is it desirable to drop them? is there any use for keeping these peers around?
**A**: dropping shouldn't happen if everyone behaves nicely, but is an adequate response to a node not paying up.
- When we say disconnect do we want to
- disconnect protocols individually when they hit accounting,
- disconnect all protocols (using .Drop)
- disconnect only paid protocols?
**A**: drop from all protocols.
- If dropped: should they be blacklisted?
**A**: yes.
- is there some existing mechanism for this?
**A**: check with core, but probably not.
- How should a node behave if it cannot send any more cheques? (without risking that those cheques bounce).
Proposed answers:
- A) (more crude) shut down the node. **A**: not this one, as it can earn back the balance.
- B) (less crude) stop the SWAP process. **A**: a quick-and-dirty alternative would be shutting down the HTTP interface.
- C) (more elegant) low-balance "mode": stop any action that would incur costs that would make the node cross the payment threshold with its peers.
→ SWAP runs normally until the payment treshold comes close for one peer, in which case actions that will cause accounting actions to be called with a negative amount are not allowed anymore, until the balance is sufficiently restored (by reciprocal service). Accounting would return to normal by doing a deposit. **A**: this is the better option: do not consume resources, only provide them.
- note: being over the payment threshold should not be a problem. being over the disconnect threshold is. **A**: nodes should not willfully go over the payment threshold, it's a buffer to deal with balance discrepancies.
- Presentation on Multiple Payments system using Honey Token and SWIP progress.

## September 26
- Chequebook persistance: Do we allow it to be easy for a node to have multiple chequebooks? For now, https://github.com/ethersphere/swarm/pull/1797 simply does not allow to connect to another chequebook if it used already another chequebook before. How should peers react when a node connects for the second time, but with a different chequebook?
## September 19
- Paying for sync. Up until now, syncing messages were not priced. In the track sync of 16/09 (https://hackmd.io/OzWXSSFxSHG90k-f2jF5Ew), Viktor suggested that syncing should have a price. What is the rationale behind this, and how does this relate to postage?

Please add your agenda points, topics to discuss to this document.

## September 12
- SWAP compatibility between different blockchain networks (e.g. rinkeby vs ropsten) _topic by Marcelo_
- Contract address should include network id. It is a bad idea for security reasons to allow nodes to connect to the network if they are using different blockchain networks (backends). Allowing this could enable potential attacks, nodes could pretend to be other nodes (impersonation) or force peers to sign data (and release it) that otherwise they would not have signed.
- Ralph suggestion: The backend url is not very suited for this. The proper way to do it is to run the net_version rpc call against the backend. This is already done in Swarm when detecting which ens address to use (see detectEnsAddr in swarm.go). We'll have to do it in a similar way with the swap backend url (both to ensure that both nodes are connected with the same network but also to discover the contract factory address in the future).
- Action item: create an issue to handle this situation.
- The check could be done during bootup or during handshake. We need to think what is the best option.
- it seems that no additional information needs to be added to the handshake.
- it is possible to check the contract address against the blockchain.
- there is information in the blockchain to check if a node is in the same network as its peers.
- maybe we can check more than once, e.g. every time a check is sent / received.
- All nodes connecting to the same Swarm network should connect to the same blockchain network (same network id).
- To simplify configuration for users we could map bzz network id to blockchain network id.

## September 4
- **Cheque cashing strategy**: right now we cash cheques instantly. What would a better strategy than this look like? Should it be configured by the user? (we might create a SWIP for this) _Topic by Incentives team._

- Conditions:
- Hardcoded: It can never cost more to cash out a cheque than the amount received
- Configuration: Time, amount

- **Smart Contract security**: (Ralph is the expert on this one) it seems our bytecode comparison is not enough to truly verify a deployed SC. The details are in issues [#1583](https://github.com/ethersphere/swarm/issues/1583) and [#1641](https://github.com/ethersphere/swarm/issues/1641). We'd like the POV of the Research team on this before proceeding with an alternative. _Topic by Incentives team._
- Solution:
- For now, try to go with the easiest solution, which probably is the factory pattern + set a default contractAddress in the code and be able to override it by flag (see how EN in Swarm is treated).

## August 29
- Adjusting Payment Tresholds (see: https://swarmresear.ch/t/adjusting-payment-thresholds/42). Topic by Rinke
- Postage stamps status? Topic by Vojtech.