This repository has been archived by the owner. It is now read-only.

Blockchain Escrow for SC <-> SF Transactions
  

Updated Aug 2, 2017

This project doesn’t have any columns or cards.

Menu

Blockchain Escrow for SC <-> SF Transactions #5

  
Updated Aug 2, 2017
Currently, all trading of SF involves a trusted escrow agent. The Sia blockchain currently fully supports trading SC for SF in a trustless way without the need for an escrow agent, so we should add it.

Currently, all trading of SF involves a trusted escrow agent. The Sia blockchain currently fully supports trading SC for SF in a trustless way without the need for an escrow agent, so we should add it.

The process is a little complicated.

  1. The users will need to decide separately how much SC they want to trade for how much SF. Then they will each instruct their wallet to form a partial, unsigned transaction. That transaction will contain the outputs - the SF going to the destination address, and the SC going to the destination address, and then it'll will contain the inputs that they know about. If you are the user sending the SF, it'll contain the SF inputs. If you are the user sending the SC, it'll contain the SC inputs. It'll also contain any required change addresses.

  2. The daemon will feed some hex to the users that contains the inputs, the change addresses, and the signatures. These users will need to share that with eachother. The signatures will need to cover the known inputs, and also the known outputs (the change addresses, and the outputs for the SC and SF). Then one user sends this data to the other. That data can be used to complete the transaction, resulting in a transaction that has the right inputs, has change addresses, outputs, and all required signatures. If done correctly, there is no risk that either user can steal funds, and there is no risk that a third party can steal funds.

So, this is an interactive process, but there is only one step of interaction. First you decide the terms, then you will out your half, then the other person sends you their half (or you send them your half), and then the transaction is complete and can be broadcasted. The person sending the SC will need to be the one paying the transaction fee, and given that it's a high value transaction, it should default to a very high fee (perhaps 3x the 'max' value recommended by the tpool).

The hardest part for this I think is going to be the GUI integration, but let's start by getting the right endpoints together for this interactive protocol.

Activity

    Loading activity

Archived cards

Loading archived cards…