Elders paying adults who are promoted to elder status is great to keep adults around but could be problematic in that rogue elders would stiff adults as you point out, which can serve as a mechanism to detect bad elders since the newly promoted elder can report them. But it’d require consensus and sync to verify the report and take action against the bad elder.
An alternative that sticks to the old paradigm would be for clients to pay all members (elders and adults) of the section directly, with elders returning enough payment acknowledgment signatures to the client for the latter to aggregate as proof of payment and right to upload. As with your idea, a synced store cost isn’t necessary, and this path ensures that if an elder reports an incorrect store cost, the extra payment is shared between all members of the section, thus removing the incentive to request an inflated store cost from clients.
Inputs: dbc from client Output: dbc to Section membership
Section membership would be a special address field that would translate network-side to all of the public keys of section members and incorporate some distribution formula of the store cost paid by the client. The client would have no ability to modify the Section membership field so if enough elders acknowledge payments, it can be assumed that all of the adults also got paid.
This path would ensure all participants are paid without delay and without requiring any trust or consensus. But it does remove the incentive for adults to stick around for a long time until elderhood to get paid.
Just to make sure I understand this, are my additions in bold correct?
Process would be (buyer is A and merchant is B)
A->B Here is a SpentBook entry that A has not signed yet that if it was signed and written would give you the cash
B signs a "payment proof identifying this unsigned SpentBook entry) and sends back to A. A can now prove B has agreed to the payment from A
A signs the SpentBook entry and writes SpentBook
Now at this point it’s interesting. The SpentBook output DBCs are visible in SpentBook but not necessarily transferred to B So we have 2 main options
A can send to B
B can retrieve the spentbook output DBCs from step 1 because the spentbook entry location can be calculated even without the signature from A and ask the mint to sign them (again etc.) and therefore has them (note anyone can ask for the outputs to be signed, it makes no difference)
If step 1 is already signed by A then B could get the mint to sign it and obtain the dbcs for themself before they send proof of payment to A.
There’s some subtlety here, eg in step 1 it would be expected that A has signed the message to B but not the dbc for B.
Yes, @mav your additions are correct and a nice catch as it means B cannot write the SpentBook without giving A proof of payment. So here A is saying I wish proof of payment before agreeing to send the cash, which for us means writing the SpentBook. It’s safe for B to sign the proof of payment as it’s only valid when A writes the SpentBook so no real risk for B to agree to proof of payment.
Yes, another good catch this is a subtle thing we should not ignore. Many messages now have no real source that matters and that is good, so this is perhaps an op → RequestProofOfPayment that is signed by A and not necessarily the whole message (as we have a pattern where the message could be delivered on USB sticks if necessary).
In my opinion, this is pretty much the same as UTXO in bitcoin. UTXO is the set of all unspent transactions, so it seems to be a kind of tokens that can be consumed in the future. UTXO uses the concept of ‘spent’/‘unspent’ and input/output part of transactions, which seem to be the same as spentbook of DBCs.
However, Bitcoin nodes create a global state with all UTXOs by using the history of all transactions. But spentbook of DBCs is a kind of history of the spent transactions, so it needs to keep more data than global state.
I think it would be able to use UTXO concept instead of spentbook for DBC.
This is not reflecting the reality of the spentbook though.
The spentbook is not a list of dbcs that can be spent. It’s a list of dbcs that have been spent.
In bitcoin there are 3 sets of txs:
mempool, txs that aren’t in the blockchain yet but are valid and will hopefully soon be added
utxo, txs that are in the blockchain and have outputs that are not yet spent but may be spent in the future
spent transactions (not sure the exact name here) which is txs where the outputs have been spent and could be pruned by a pruning node, which cannot be spent a second time in the future.
The dbc spentbook doesn’t store 1 or 2, only 3.
There’s no mempool kept by the mint nodes of transactions that are ‘pending’ addition to the network.
There’s no ‘current set of dbcs’ kept by mint nodes of valid-but-unspent dbcs. Each client has their own utxo set (ie what lives in their wallet), but nodes don’t have this - not the full set of utxo, nor any partial set of utxo. When using blind signatures, mint nodes sign the blinded new dbc, not the new dbc itself, so nodes never even get to see the list of currently unspent dbcs.
The spentbook only stores dbcs that are fully spent. Any unspent dbc (in bitcoin called a utxo) is only seen by the sender and receiver, and is not known to the mint nodes until after it’s spent (this is quite hard to understand when using a blockchain perspective, it needs a good understanding of how dbcs and blind signatures work).
When mint nodes sign a transaction they check the incoming dbcs has been spent, unlike bitcoin where nodes check it has not been spent.
It took me a long time to appreciate this difference. Blockchain gets in the way conceptually. DBCs are substantially different to blockchains.
Pruning nodes have only some of recent transactions after syncing all transactions. Thus, they do not provide blockchain for new nodes, but they have a complete set of UTXOs, so do not kind of lightweight nodes.
correct. I hadn’t thought of this issue.
good point. In UTXO, each node syncs the entire history. A concept of blocks and leader is absolutely necessary for multiple nodes to sync the same global state in state machine replication method.
But, spentbook has only one database in the SN network. no need to leader and blocks.
The idea I came up with while reading your post is that it would also look good to implement a spentbook without fork/merge actions by introducing the mempool concept to the spentbook of DBCs.
This sounds like a farmer will never be paid unless they become an elder. And what if the person running the elder node spends their SNT before distribution? Not a question of honesty but the person wishing to use their earnings which most people will want to do.
Couldn’t one modify/generalize this process to allow for a flexible farming algorithm capable of pay on put, pay on get, ptp, ptd etc? In this scenario, network is A and farmer is B.
A->B Here is a SpentBook entry that A has not signed yet that if it was signed and written would give you the cash for providing a specific/verified resource.
B provides the resource and then signs a “resource was successfully provided proof” identifying this unsigned SpentBook entry and verification that the request from A was completed) and sends back to A. “The network” (A) can now validate the claim and prove if farmer B has actually provided the needed resource/function/task and agreed to the payment from A for doing so.
this is a subtle thing we should not ignore. Many messages now have no real source that matters and that is good, so this is perhaps an