You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am making this issue as a place to temporarily drop some payments code/idea, since we don't have a module/crate for it yet.
In the real world, there is cash, and then there are wallets, cash registers, invoices, contracts, payments, receipts, etc that represent infrastructure built around the cash to facilitate its use and transfer. The infrastructure is separate from the cash and is normally created/provided by parties other than the cash issuer (ie mint, central bank).
I think of DBCs as the coins/cash equivalent base layer.
So I feel it will be cleanest if we enforce a similar separation/firewall between our "cash" and our payments infrastructure. For one thing, this keeps the footprint of the cash layer smaller, and thus easier to review/audit. It also may open the door for 3rd parties to provide alternative payment infrastructure more easily. Let 1000 flowers bloom.
I think a good approach would be to keep sn_dbc for the dbc/cash, and then make sn_payment (or maybe sn_dbc_payment) for the infrastructure around it. We could (possibly) keep both sn_dbc and sn_payment in the same github repo, so that the crates are more tightly bound together when making changes. Actually, I'd prefer not to do this, as it also binds together issues, pull requests, etc. But we could discuss about it.
Anyway, here is the payments data structures that we came up with in a recent meeting.
// seller commits to a price.
struct Invoice {
amount: Amount
payto: PublicKey,
seller_signature: Signature,
}
// buyer pays it.
struct PaidInvoice {
invoice: Invoice,
payment: Payment,
}
// A payment looks like
pub struct Payment {
dbc_packets: Vec<DbcPacket>,
memo: Vec<u8>, // should be fixed size?
}
// public bulletin board,
// sender puts Invoice + Dbcs up on bulletin board.
// shows that sender made payment. (without obtaining a receipt)
// Requires interaction/trust. atomic swap protocol?
// struct PaymentReceipt {
// payment:
// signature:
// }
The text was updated successfully, but these errors were encountered:
I am making this issue as a place to temporarily drop some payments code/idea, since we don't have a module/crate for it yet.
In the real world, there is cash, and then there are wallets, cash registers, invoices, contracts, payments, receipts, etc that represent infrastructure built around the cash to facilitate its use and transfer. The infrastructure is separate from the cash and is normally created/provided by parties other than the cash issuer (ie mint, central bank).
I think of DBCs as the coins/cash equivalent base layer.
So I feel it will be cleanest if we enforce a similar separation/firewall between our "cash" and our payments infrastructure. For one thing, this keeps the footprint of the cash layer smaller, and thus easier to review/audit. It also may open the door for 3rd parties to provide alternative payment infrastructure more easily. Let 1000 flowers bloom.
I think a good approach would be to keep sn_dbc for the dbc/cash, and then make sn_payment (or maybe sn_dbc_payment) for the infrastructure around it. We could (possibly) keep both sn_dbc and sn_payment in the same github repo, so that the crates are more tightly bound together when making changes. Actually, I'd prefer not to do this, as it also binds together issues, pull requests, etc. But we could discuss about it.
Anyway, here is the payments data structures that we came up with in a recent meeting.
The text was updated successfully, but these errors were encountered: