swaponline/sips

Swap.online Improvement Proposals

sips's Issues

Создать swap implementation standards checkbox list

Идея

Прошу обсудить идею (назовем данный тикет не issue а неким Implementation Flow Improvement Proposal)

Создать список чекбоксов, где каждый чекбокс описывает конкретный принцип, требование или тест имплементации протокола, которые должны быть выполнены или соблюдены перед тем как имплементация свопа конкретной пары пошла в мейннет.

Каждый чекбокс при этом отмечается по мере имплементации свопа между конкретной парой.

Каждый чекбокс должен содержать назавание принципа/требования/теста и ссылку на более подробное описание, мотивацию и обоснование, возможно с примерами имплементации.

Для каждой версии протокола обмена у нас будет своя версия такого списка. При этом каждый чекбокс может тоже иметь свою версию.

Примеры принципов/стандартов/требований/тестов

This is a checkbox list for implementation of atomic swap of dogs for cats version 1.0

• Make sure you don't exchange less than 2 cats for dogs. Minimum cats requirement v0.1
• Make sure the dogs are clean. Cleaning dogs standard v0.3
• Make sure cats are passed over first. Cats always go first principle v0.43
• Make sure the cats are not pregnant. Pregnancy test procedures v.1.23

Из более реальных примеров чекбокосов:

• проверка длины секрета
• маркет тейкер - всегда хранитель секрета

Шаблоны

При этом при создании тикета на имплементацию свопа конкретной пары, всегда будет висеть шаблон, в котором уже будет иметься checkbox list самой актуальной на данный момент версии

Milestones

Чекбоксы могут быть разделены на milestones. То есть у каждой имплементации может быть разная глубина. Например - только Basic Swap имплементация - бесплатный медленный своп (то как это происходит сейчас), Faster Swap имплементация - ускоренный своп, когда маркет тейкер подписывает сразу 2 транзакции (send + claim), Destination Address - фича с кастомным адресом назначения, Prepaid Claim фича - платный когда мы сами оплачиваем "claim" своим эфиром итд итп...

2 типа checkbox list

1. для свопов
2. для кошелька

Страница статуса

Если мы делаем вышеописанное, неплохо было бы сделать страничку публичную, которая имеет список всех криптовалют, а так-же всех пар и на каждую из пар было бы круто видеть в реальном времени статусы имплементации, сгенерированные прямо из гитхабовских issues с боксами.

Что то типа swapready.net только наш собственный

orders: use data.identity for peer identity

Отделить адрес эфира от идентификатора

Заменить подпись через адрес data.eth на data.identity

Примерно так:

data: {
  identity: { address: '0x1DEN717Y' },
  eth: { address: '0xAbCDeF' },
  btc: { publicKey: '000ffff', address: 'MgMg..' },
}

Зачем?

Чтоб можно было в .eth класть любой адрес, метамаск или внешний кошелек. Это нужно, чтоб избавиться от destinationSellAddress, destinationBuyAddress в ордере.

SIP1: One key for multiple blockchains (BIP39 HD Wallet)

Right now you make a poor user remember two keys. One ethereum, and one bitcoin. This needs to be fixed. Both blockchains are using the same private key algos: secp256k1. According to bitcoin ():

Range of valid ECDSA private keys

Nearly every 256-bit number is a valid ECDSA private key. Specifically, any 256-bit number from 0x1 to 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4140 is a valid private key.

The range of valid private keys is governed by the secp256k1 ECDSA standard used by Bitcoin.

According to Ethereum (https://etherworld.co/2017/11/17/understanding-the-concept-of-private-key-public-key-and-address-in-ethereum-blockchain/):

Ethereum key generation is based on elliptical curve ecp256k1. Elliptical curve (EC) is intense mathematics, and there are a lot of great articles on the internet covering deep details of the elliptical curve. There are standard libraries to generate Ethereum key pair in a much safer way. In this article, just for demonstration, I will use elliptical curve Javascript library to perform elliptical curve operations.

The only difference right now is that your ethereum private key is represented in Hex format, and your bitcoin private key is in Wif format (that can be easily derived from hex format) like this:

https://en.bitcoin.it/wiki/Wallet_import_format

Now I suggest using Wif format ONLY for the private key because it contains a checksum. Then derive Ethereum private key from it. It should be straightforward. It is just a number in a range. I think either script to generate a private key will do. Bitcoin or Ethereum.

In order to make things more secure and avoid collisions, we may want to use Derived Keys (HD) for the blockchains.

Stability for Flow

Currently, Flows are not very stable. For example, you can get into the state where you should know secret, but somehow it's null. We should make Flows more obvious in the sense of data flow before releasing and having real money and users' headaches at stake.

Main UX obstacles are:

• user does not have enough balance to swap
• user already has a swap with this person

Main security obstacles:

• user lost a Swap ID – this goes to SwapHistory issue.

• second party left right after signing and I dont know that

• I froze my money, I should have all the values so I can get them back

• bad connection to server, I am not sure if money were sent

• I froze money, but second party left away – can I refund?

• we both froze our money – how can I be sure it is? double-check

• I am ready to withdraw, but I don't know

• ETH owner had lost a secret key, but his ETH were withdraw already

Given the above, we have next steps:

For brevity and polimorphism we call BTC = base, ETH = secondary

setup

Both know only the participant address and amounts to send.
We cannot leave this step until both agree on continuing swap.

sync balances

This step should check the balances for everyone. Double-check you have money you claim to have.

lock base currency

Submit secret method goes here.
BTC owner should froze his money.

The shared state adds script address and exact values.
We cannot leave until both know these.

ETH owner also checks the frozen balance is just equals to what was expected.

lock secondary currency

ETH owner locks funds on the smart contract.

This step has no additional data. That's only he should send message, that funds are ready.

BTC owner doesnt leave until he knows exactly that contract has the right balance, and the hash matches.
ETH owner does not leave until BTC owner leaves.

withdraw secondary

BTC owner does not leave this step until ETH were transferred to his account.
ETH owner does not leave until he receives the message that ETH were withdrawn

withdraw base currency

Although he has everything he needs, BTC owner waits for message to mark swap as finished.
ETH owner cannot leave the step until he makes a successful withdraw tx.

Add support for Steem and SBD

We need support for steem and SBD. account creation on steem requires Resource credits or 3 steem.

SIP6: Возможность работать в торе (полностью анонимно)

Поустпил запрос от неопределенных личностей на возможность работы через тор. Сейчас IPFS не грузится в торе, какие есть варианты и решения