does DCUtR reveal a users IP to each other? or does it use some other rendezvous mechanism?
may we get an “wallet inbox register” at some point?
a register writable by anybody that is derived from the wallet address where token senders can just upload the receive string if they wish …? so the safe client could check the network for unreceived sends to the wallet …?
when doing it like that people could pay for the register entry (kind of a tx fee) to avoid having to share a super-long receive string …?
…since the receive string will just work on the right wallet there is not really a danger to making it public - right?
Just that people could track how many payments have been made to the register and so anyone you told about it knows how many payments you are getting
and what information precisely does that contain? (+you can have multiple wallets + not all sends must be made like this … it would just be a option for convenience)
2 Likes
That you are actively receiving payments for things. A tax department might become interested in asking for tax on those if its a lot of payments and then you have to explain it to them even if micro payments worth little (like tips)
Of course this assumes you have somehow told people about your receiving address if you are receiving unsolicited payments. Solicited payments you will already know about and so you can simply receive them when they give you the payment details. So solicited payments can remain private between you and the sender
Thats the point this is really needed for payments you may not know about and so you have to (semi) publicly inform the people paying to use that record to post the payment info. Thus the tax man can know too if they see it or someone else in a tax audit mentions where their tokens are going
Much harder to remain anonymous when you have to tell people about a public central record to post their payments to.
@Shu I gather you are working on the metrics
A question please.
I am using the metrics to monitor things, and I like that its fast to respond.
The two metrics I have a question on are the
sn_node_current_reward_wallet_balance and
sn_node_total_forwarded_rewards
I see values in both and I have the owner set.
As an example in one node’s metrics, the wallet balance is 10 nanos and the forwarded rewards is 20 nanos
This is not an isolated case and usually the first 10 nanos show up in both fields and after that they are not necessarily the same
Can you tell me what is going on here?
EDIT: Request please
The store cost entry shows zero sometimes when there has already been earnings. I gather this is the same as happens in the logs. This happens when a quote is requested but the chunk already exists so there is no cost. Doing this makes the store cost value useless since its purpose in being shown is to give the metrics requester an idea of the current cost to store on that node. (ie to do analysis)
The request is that in the metrics it does not reset back to zero. If it had a value greater than zero then that value will be shown when the code puts it back to zero. IE if new store cost is zero then do not change the metrics value. I know this may require a separate value to be kept. Not a max value just the last value.
I don’t think you mean the current update but just for info, the issue is present since this update along with the others I have encountered: all are there and are not dependent on a poor connection as they are occurring when done on a VPS (see API issues with updated network continue and are not due to mobile broadband · Issue #2019 · maidsafe/safe_network · GitHub).
1 Like
But this means the storecost there is only updated when someone queries a quote… And not because the parameters that determine the storecost change…
I was told a while ago that the node only calculates a store cost when requested by an uploader.
And this is also what I am seeing in the panel I am scripting for my testing I will try on a local network. At the moment its for the live network.
Also we were told that if a uploader requests a quote for an existing chunk then the store cost value returns to zero only to be calculated again when next a quote is requested off of it
1 Like
Yeah - I just thought that simple multiplication task might be executed on a more regular basis/on request if the metric would be exposed by an api (so a dashboard would reflect a clear and up to date picture)
… The nodes do way more cpu expensive tasks all the time…
1 Like
It’d be good if the metrics read would cause the calculation to be done. That way the only extra time it is calculated is when a web call to the metric page for the node is done
@joshuef An update on the general state of the network since the start of the update based on use of a mix of ‘safe files upload’ and my app to create and view data on the network:
- as reported in issue #2019 I’m seeing all the issues I’ve been seeing previously, though now they are confirmed from VPS (so not related to my mobile broadband connection)
- by ignoring errors and repeating the process, myself and two others did manage to upload websites Tues-Wed and all were viewable yesterday (Wed).
- today (Thu) I’m unable to view any of the sites. Failures are occurring at all stages when getting (sync’ing) a register, getting a metadata chunk, getting a self-encrypted file (e.g. missing chunk).
- I’ve also seen a new error today a few times, where the following is reported when trying to access a register. These messages are output when trying to sync a register for read (not to create/update/pay for one), when really there shouldn’t need to be a wallet or the private key.
VersionsRegister::sync() - this can take a while...
Successfully made payment of 0.000000000 for a Register (At a cost per record of NanoTokens(0).)
Successfully stored wallet with cached payment proofs, and new balance 0.000000591.
Failed to load versions register: Wallet Error I/O error: No such file or directory (os error 2).
Caused by:
0: I/O error: No such file or directory (os error 2)
1: No such file or directory (os error 2)
Location:
src/awe_website_versions.rs:434:25
Note:
A website consists of 1) a register, 2) an unencrypted chunk of metadata for the site, and 3) one or more files which make up the content of the website, which are referenced in the metadata. Each entry in the register points to a metadata chunk and the entries correspond to a series of versions of the website.
7 Likes
Thanks @happybeing .
There’s some fixes being tested and touted and other issues you’ve noted are being looked into! 
9 Likes
Cool. Some improvement since that summary:
- some data that was not there is now ok and I can load the registers which @aatonnomicc and @riddim created for their sites. I haven’t checked if all their data is there but both sites load - need to check the site resources more fully
- I have been able to create a new registers which are working, so hope to have an
awerelease today. (FYI I need working sites to do a release,aweitself works on Linux).
Some bad data remains
- the register reporting a ridiculous number of entries is still doing so, so I think there is corruption there
- I still have issues uploading sites at various stages but repeating enough times I can eventually succeed (due to having lots of donated nanos - thousands per day atm).
8 Likes
I believe this might be due to some unintended usage in the APIs here. (Coupled with a lack of update sync for registers just now). Added clarity and register replication-on-sync behaviours are in flight that should help here.
(@qi_ma has been looking at this)
4 Likes
The issue wasn’t quite as described. It wasn’t a corrupt register, but the network was returning the register with zero entries (even though two values were written immediately after creation using merge online, and many many updates had happened subsequently).
My code wasn’t handling the case of getting back an empty register, so reported it as having U64_MAX-1 entries!
3 Likes