Pre-Dev-Update Thread! Yay! :D

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.

3 Likes

Yes, and I thought that risk was a bit too high.

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 :slight_smile:

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.

11 Likes

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.

2 Likes

They cannot, because of this:

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 :slight_smile:

(There are a couple of more details that I’ve left out for brevity.)

8 Likes

:+1: I can’t wait for fees to be implemented. We’re so close to a full function network I can smell it. :nose:

Go team!

14 Likes

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 :slight_smile: )

9 Likes

Noooo, don’t say that. Rob will multiply it by four! :scream:

6 Likes

Doesn’t necessarily mean much, just a bit more than this basic data stuff getting more solid :slight_smile:

8 Likes

Are fees in yet?
Are fees in yet?
Are fees in yet?
Are fees in yet?
Are fees in yet?

:rofl:

4 Likes

Oh the reason encoding is that it was a fee payment DBC, not a reason code the client gives it, I understand now, thanks

8 Likes

Want a testnet named after you and keep all your toes?

Try being first to wrap safenode up as a mobile app and run it on a phone.

7 Likes

@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

1 Like

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:

  1. 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

  2. fee-per-transaction is much more complicated and would take even longer than fee-per-input to fully implement and debug

  3. 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.

  4. 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.

9 Likes

Fees were removed yesterday, but equally importantly disk backed storage was merged today.

11 Likes

Lets go!!
20230509_151108

13 Likes

Can’t wait to have my platters pleasured.

My platter has been pleasured, much chunkage

3 Likes

Could you perhaps explain to the lesser informed what exactly this means?
Provider vs data records.

This allows KAD to store the Records to fs instead of memory.
Only data Records are stored to disk, ProviderRecords are still stored in memory
5 Likes

Yep, I just ran out of it.
Nice to see chunks on disk again though.

5 Likes

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 :slight_smile:

Now we can at last think of these things in a clean way

15 Likes

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.

2 Likes