Even if some value could be extracted this way, it seems a shame for only a slice of any fee paid to be redeemable, and for fees to never be redeemable immediately seems like a big issue (if the cost of spending a fee = the value of the fee, you didn’t receive any value, so have no incentive to provide actions to receive fees).
If combining can be free that is good, as long as it can be done in a way that avoids a spamming opportunity, which it shouldn’t if it only relates to fees received.
It can be. And it would only be fees possible to merge for free. So no spam-vector.
As nodes would only accept payments with proper reason encoding (as otherwise they can’t merge them for free), and only allow free merge of such DBCs, they would collectively enforce that.
And they would all have interest in enforcing it, as their rewards depend on it
The merge also should be in a proper format to be allowed.
So a minimum input number and a single output. To make it all efficient as well.
There will still be the minimums and during those the dust accumulates. And the greater the use of DBCs the faster this would happen.
This would be great as long as people couldn’t do “faked” transactions by claiming amounts were fees when they were not.
This seems to be a good idea if it could be implemented. Perhaps when the to & from address is the same the transaction is free. Although this could open the door to flooding the network. But then again there is a limit to recombining since the attacker has less and less DBCs to work with as they do this and splitting only costs them fees.
Having said that any recombining that ends up at the address it came from cannot be spammed since in the end there is only one DBC.
And nodes would reject any input (thus whole tx) with that reserved reason encoding that isn’t a fee payment to them.
As every input require majority nodes, rogue nodes can’t make it happen.
This is neither necessary nor possible, due to the single use keys.
The above described protocol is enough
(There are a couple of more details that I’ve left out for brevity.)
I think that may still take some time.
And there is still the fee-per-tx idea, that I know some probably want to investigate more. (But from what I have seen, that will be much more complicated. So we’ll see basically )
@maidsafe
A feature that i would love to see is the ability to recombine dbcs without fees, not essential as far as I can see since fee is on the transaction and not inputs, but would be a good feature in my eyes
It would be a mistake to remove the current implementation of the transfer fees. Even if fee-per-transaction is the ultimate preferred design, removing the already implemented fee-per-input design would be going backward and introduce a lot of delays. Here’s why:
fee-per-input took a lot of time and effort to implement on the section-based network and was then ported over to the current libp2p network, which took time and effort too but was helped by the previous work
fee-per-transaction is much more complicated and would take even longer than fee-per-input to fully implement and debug
Keeping the already working fee-per-input allows for moving ahead with testing payments and downstream components like node wallet design, payment to nodes, bugs, testing and usage by community, fee levels and schedule that brings about desired client and node behaviors. All of that would be blocked and have to wait for a complete reimplementation of fees if the current implementation is removed to wait for re-implementation as fee-per-transaction.
Fee-per-transaction can be explored and implemented in the background without removing fee-per-input thus blocking progress on payments (though it would appear to Maidsafe internally that progress is being made because someone is busy implementing fee-per-transaction). Better to proceed in parallel and if established that fee-per-transaction is better (along with evaluating on extant bugs and in the field usage problems that testing fees with fees-per-input implementation may have helped unearth), then the fee-per-input implementation can be swapped for the then-ready fee-per-transaction.
This is a libp2p thing. So kinda sits on top of kad. i.e. instead of find_close_nodes to X a provider says Get me the closest nodes who are PROVIDING the service X.
For us X will be
archive nodes
DBC audit nodes (they just hold as much of the DAG as they can, probably all of it)
So these services will provide a great backup etc. Where archive nodes when full will add a prefix and drop half the data etc. (i.e I now hold only data beginning with 1) then as they fill they go further (i…e I now hold only data beginning with 10). And so on.
Kad is where Safe nodes must hold data, they hold the data close to their address only and these nodes will be tiny. So there we have our data and our SpendBook etc.
i.e. a provider provides a service on the network. We will use them as above, others may use them to do their own thing, i.e. provide AI models and so on (something I am keen on). These could collect requests/responses anonymously and retrain continually and many more experiments like that. Then hopefully move to core models with a layer of personalisation on them for each users. So uses have a more personal AI that knows the level to converse at and so on.
Then of course robots
Now we can at last think of these things in a clean way
Unfortunately I may not be at my computer in the evening, so the likely testnet might need to exist without my participation until tomorrow - and I’d need to exist without it. Let’s see.
Anyway, nice to get disk storage back. It’s might also be a way to see if you are really connected or not. Last time I seemed to get node in, but couldn’t understand from the logs, if I really stored something, or if I was just pseudo-connected.