Skip to content

Instantly share code, notes, and snippets.

@luke-jr
Created April 18, 2013 03:38
Show Gist options
  • Save luke-jr/5409899 to your computer and use it in GitHub Desktop.
Save luke-jr/5409899 to your computer and use it in GitHub Desktop.
Combined and debt transactions

Terminology

Btransaction
blockchain transaction (a "normal" transaction)
Ctransaction
combined transaction (also a valid Btransaction)
Dtransaction
debt transaction (NOT a valid Btransaction)
Ltransaction
logical transaction (concept of transferring money from A to B)

Combined transactions

Ctransactions are Btransactions with version=2

Ctransactions without all their signatures in place can be broadcast on a p2p connection using the new "ctx" message (which is otherwise the same as the "tx" message)

When Ctx-capable client wants to send:

  1. Take the most recent (at your choice) Ctx seen on the network (and not mined)
  2. Add your inputs/outputs (possibly rearranging the order of any inputs/outputs)
  3. Update the locktime to the latest block
  4. Add your signatures
  5. Broadcast Ctx via new message (can also broadcast a new Ctx via old message)

When Ctx-capable client sees a new Ctx with your inputs unsigned:

  1. Verify all the outputs you cares about are still there, and the fee is within an allowable amount
  2. Sign your inputs (optionally add in signatures from compatible Ctx seen)
  3. Broadcast Ctx via an old message if it now has all signatures, or a new message if not

In order to handle Ctransactions, miners should allow transaction replacement provided all outputs of the new Btransaction are a superset of the old Btransaction.

Debt transactions

Debt transactions require unique user ids, which can be used to express trust. User ids are HD wallet chains, in some base58 encoding. Users should be able to add people they trust and set an amount of total debt they will accept from others before requiring settlement. Every signed message should use a unique child number; this is variable-length, and longer than 4 bytes should be taken as a child chain. Communication can (should?) be encrypted to a key signed by the other party

Each party needs to know:

  • Ltx scriptPubKey
  • Dtx scriptPubKey
  • amount
  • who they are trusting
  • Dtx scriptSig

To send a transaction:

  1. Generate a unique Ltransaction keypair
  2. Identify a trust route from you to destination
  3. Create a Dtransaction between each set of peers
    YOU -> PeerA (trusts you)
    PeerA -> PeerB
    ...
    PeerY -> PeerZ
    PeerZ -> Destination
  4. Each peer signs the Dtransaction FROM them
    During this process, peers may opt to request settlement Btransactions
  5. YOU sign every Dtransaction
  6. with both signatures, each Dtransaction is now a valid debt; balances should be adjusted immediately as confirmed

To redeem a Dtransaction:

  1. Debtor contacts creditor:
    Settlement Btx scriptPubKey
    Fully signed Dtx
    Dtx scriptSig
  2. Creditor sends back a transaction to be broadcast

(Optional: Creditor may choose to use a Ctransaction and maintain it on his own end)

@oleganza
Copy link

Since you don't need to trust money to friends (never a good idea; it more often destroys relationships than strengthens them), more people can arrange a bigger network. So you have a much greater chance to find a path from you to me. And the more useful the network is, the more nodes will join to make fees smaller and paths shorter.

@ABISprotocol
Copy link

Thank you @luke-jr and @oleganza - keep on keepin on

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment