“This makes the Mint’s task read-only, the Mint only checks the spentbook for transaction commitments for each input DBC to verify that all inputs are committed to the same transaction and validates the transaction balances.”
They have their own way to manage tasks. You don’t need a MaidSafe agreed view that covers everything. You are given an area of responsibility and work informally with whomever you need to, to establish the details and parameters. You get on with it and communicate with those who need to understand how your work is proceeding.
All this can work efficiently in a small team. In large teams you can’t do this, or where there needs to be tight budget and timescale management. Here neither apply, so a small team can work informally and much of the task management can be done by the individuals or pairs working in a particular area, maybe never written down.
I’d be very surprised if there was one person with a list of everyone’s tasks (because to be useful each task would have to be defined in detail, not just a handful of words). But even if there was, publishing it would create unnecessary work and slow the developers down as I’ve explained.
My understanding is that at this stage of development the list of features or rather requirements is fairly short
Clients need to be able to connect reliably to the network
Data needs to be stored with redundancy and without loss
Data needs to be reliably retrievable
The network needs to be able to scale by smooth section splits
The network needs to be Byzantine fault-tolerant
The network needs to be ‘usable’ in terms of speed of data uploads/downlaods, CPU and memory consumption (can be optimised later)
The network needs to be stable and predictable
There needs to be a usable front end (CLI in the first instance)
There needs to be a workable economic model and means of transacting
With the exception of the last two points the rest are all closely connected mainly revolving around a small number of building blocks, particularly the sending of messages between nodes and AE. So progress in achieving one milestone (eg clients connecting reliable) will be immediately transferable to other areas because of this building block approach.
With each building block being worked on by an individual or two, progress, when it happens, can be rapid, but because progress is not linear or particularly predictable it’s not amenable to a tickbox approach.
John, those are requirements/specification rather than tasks. The key difference here is that some requirements might be ticked off as you go, but many will only be met when the network is finished. Whereas tasks can ask be ticked off as they are completed so give a better sense of both progress and remaining work to completion, although neither are very reliable.
Is that really true though? Not so sure here as I’ve skimmed the reading while multitasking. The clients write to the SpenDBook first, then need it validated before they can spend it. So spenD is a better descriptor, no? Only after validation is it done and dusted, right? SpenDBook it is.
Yes it is true. It’s a list of spent transactions, not a list of dbcs that clients are able to spend.
Transactions that are written to the spentbook are now spent. The stamp of approval that comes after that from the mint only adds authority, but does not change it from being spent. Once the client writes to the spentbook there is no second chance to spend it differently, so it’s spent.
The literature for dbcs uses spendbook, I personally feel it’s a spentbook, and the difference is important for building an intuitive understanding of what this thing is.
Spend is a verb. It’s implying that the book lists something that’s ‘in motion’ or ‘happening’. This isn’t the case here.
Spent is an adjective. It’s describing the state of the data. It’s in the past, spent, not able to be changed, which is an accurate description.
To use a bitcoin analogy, spendbook would be utxo (ready to spend, able to spend etc), which the dbc record is not doing. The spentbook is any transaction that’s completed, ie the bitcoin blockchain not including utxo. It’s an important distinction since it affects how we can use the data, eg can it be used for an audit or not? Can it be used for linking history or not?
Maybe the “spendbook”/“spentbook” term could be replaced with something more descriptive altogether. The writing to the book by the client definitely infers a kind of journal or ledger but then the authorization to disseminate funds goes a little beyond a simple journal/ledger, it entails some kind of disbursement mechanism, if that is included in the spendbook’s realm of responsibility.