Combined and debt transactions

combined_and_debt_transactions.md

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)

Note to self: There should be a way for Dtransactions to cancel each other out.

Combined with these bilateral deposits, you can replace "trusting user ids" to "trusting any node that agreed for having mutually locked up funds". This allows connecting/contracting with random nodes completely automatically. Your app may choose nodes based on your location and their fees.

https://bitcointalk.org/index.php?topic=273539.msg2933633#msg2933633

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.

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