Thx 4 the update Maidsafe devs
It’s incredible that we’re now in a place of bug fixes and tweaks. 
for the valuable feedback from the community.
Keep hacking super ants
16 Likes
I think it’s deeper than just saying we blind the amount though. If we unblind them to store data dn many folk store data, it becomes an issue. The blinding is also a regulatory issue, but I am not saying we are doing this for that reason. It is a thing though.
So when we first did the DBC code, it was super simple, we were keen on forcing one time keys. That was good enough for me, by far. But then it was taken much further with commitments, bulletproofs and ringct. We even created a ringct and bulletproof code for BLS.
So let’s look at just plan single use key DBCs a bit more.
- They are simple (I love simple, especially with security).
- They are fast (I really love that).
So simple, fast and with single use keys. I wonder how non anonymous that really is? I here folk say hide everything, hide the amounts (which I do quite like), hide the sender an receiver (which is very tacky in my eyes as there is no known cryptographic way beyond decoys and I really think that is a false route).
If we have lots of keys sending to other keys, then it’s likely anonymous.
If folk transfer cash to each other via signed contracts, then it’s not. If they buy X to be delivered to Y, then it’s not. Especially if X demands KYC or other less obvious ID, like your name and address.
So I think the issue is much deeper. But if we have DBCs as we have now, simple and fast then we may have some thing quite different here.
It’s not.a blockchian and it’s not a set of inputs and outputs to be checked against a single ledger. It’s fast because it achieves seomthing quite remarkable, parallelisation. So you could be spending in group A, me in group B and so on. Neither A or B need to communicate, ever. So this is a very parallel network. I watched a 3 hour chat with an avalanche guy who said they try but are not sure if that’s ever possible, ,but if it were then it’s a game changer.
So we could go ringct and more, but that stuff breaks and I fear it will break badly. Bulletproofs/commitmemnts are more stable, but add layers of complexity that will slow down the network a lot and also make it v hard for devs, app users etc. to pay for goods, especially if they need to verify how much they paid. It’s quite involved, way more involved than a simple transaction. People don’t bitcoin as it’s hard, add another layer on that and then I feel it can become technically great but unusable for most.
I am sure we will discuss this much much more, but I think simple, fast and one time keys are likely much more secure and private than we imagine.
29 Likes
Honestly, and I don’t know how, I forgot about one time keys 
. Us privacy minded folk must love backstops and overkill though.
One time keys is quite anonymizing indeed and similar (but better yet) to using one time anonymous accounts. It likely is good enough. Any sense of what regulators think of one time keys and if that puts it in the category of a privacy coin?
Btw, trust your approach 100% and the drive for simple (and fast) is the best goal.
21 Likes
I am not sure, but it feels less like us using dark web type terminology. I feel one time keys means the off grid/out of the rat race folks will be just dandy. I imagine groups interacting together and using SNT like cash and being anonymous too.
Thanks @Nigel I trust this community to ask the questions that need asked, it’s brilliant.
22 Likes
Approaching regulators by framing the use of one time keys having practical utility/uses such as off-line, gift cards, etc etc that relates to catastrophic events and/or everyday life as a benefit is a great idea.
14 Likes
Anyone feeling like the network will just start working soon? Basically, like just start buzzing along, online, yet devs still tinkering away at it updates-wise (got to add things like DBCs and system restore and all these other things that keep escaping me since foundational ideas kept shifting).
15 Likes
That is BTC effectiveness. The addresses are anon unless you tie it to some identity, eg though an exchange or spending to a identifiable address. The quote above would be the same as that. As soon as you know what account sent the tokens to a receiver, then at some stage the potential for tracing like in BTC becomes available.
Thats a good way to see transactions as gift cards and is along the lines of this idea too and that one time keys are the carrier of tokens till send on, a digital transport if you want, or a gift card and not the blockchain ledger idea where there is a central ledger. The key is only a digital transport identifier to transfer a thing and not a key in some global ledger. Maybe like a consignment number.
@dirvine Weren’t we using deterministic keys where you could receive on one key and send using a derivative (?terminology?) key. Thus the receive key is not the sending key.
Also refer to the DBC key as just the DBC transport key and thus tokens once sent never have the same key as before. Not a anon/privacy thing but just a “transport” number/ID. Also change the terminology into accounting terms used for cash transactions thus making it look a lot less like anonymity/privacy and more like normal accounting practices that used to occur when it was a total cash society. IE very simplistic and minimal. Would seem to be the correct way as well since tokens are more like cash than bank accounts.
13 Likes
We do have key derivation. So sending to a recipient you send to a derived key. They can create the corresponding secret to spend that. I hope this makes sense, but it’s like this
- You have address ABC
- I send to the address ABC+some code (easy way is I send to ABC+MyPubKey)
- You get the derivation index (i.e. MyPubKey)
- You create secret key and can spend those funds
So the nice thing is any key you publish will not receive coins, they all go to a derived key.
Pro:
- Makes tracking much harder
- Removes a publicly known address from the receiving address
Con:
- Client wallets MUST implement this properly as sending to ABC will be lost money.
However a smart person would publish ABC and then spend it. Any wallet trying to send to it would see it’s spent and not proceed trying to send to ABC. So wallets MUST send a derivation index fro ABC to you and properly coded wallets will.
Just like today a bad BTC wallet won’t last long. in the market. Same will eb true for Safe wallets.
21 Likes
EDIT: I’ve got it, no need to explain, will write my understanding up later.
7 Likes
Below is an update video created by chatgpt plug-in Visla. A few keystrokes and minimal effort produced… something.
A $20 monthly subscription is required to fit full updates in and remove watermarks etc.
What do you think, does it have legs?
5 Likes
Seems kinda neat but I don’t know I’d spend my money on it yet. The AI voice over wasn’t very natural but maybe they have other options with paid version? Would they just be posted to YouTube so people could share the link? I don’t necessarily see these driving traffic or views on their own.
6 Likes
I don’t know that random images is of any use, well it is not of any use but I do see value in being able to listen on the go.
There are a few options, whether any one is better than the other is debatable.
6 Likes
Was going to suggest tugan.ai because I’ve had amazing results but now it’s $37 a month. It’s something I may get to accomplish some things but not sure yet. If I do though then turning the updates into email newsletters might be a good idea. Emails have the highest conversion rate. Just need a way to get them.
7 Likes
But they have to sample @dirvine’s voice and use that. 
6 Likes
Why not my spelling and grammar, it’s my golden canary. Everyone would know it was not me unless there were the usual sdfopjsdf[ words in it 
9 Likes
Great post, I love reading your statements where you explain the current state of affairs in a simple way. Thanks for the explanation and thanks to @nigel for the picking up of the topic.
Coming back to DBC, I think any solution should be as simple as possible - but not simpler! 
So I think the current one-time key solution is a very good choice.
In my opinion, anonymous accounts sending digital cash to each other guarantees the privacy of transactions, so I think the current solution is optimal (simple, private and fast, and inherently safe). And if it turns out that an additional layer is needed in practice, then it can be considered and added.
The best solution would be to be able to guarantee the autonomy of the DBC, as with SafeNet, then the issue of regulatory requirements would be definitively resolved, because after all, physical cash is completely anonymous and no regulator is able to track or challenge the parties’ statements on the transaction.
11 Likes
Coming back from the dog walk (always a place of solving some complex problem without thinking about it) I’m now less sure I understand this but here goes and please @dirvine point out my blunders…
My interpretation:
- “address ABC” is a public key of the recipient, so by sending to it you are creating a DBC which can be spent only by the owner of the private key for address ABC.
- “I send to ABC+MyPubKey” means sender creates a new public address and sends to that. By telling the recipient the value of MyPubKey, they and only they are able to derive the private key corresponding to ABC+MyPubKey.
However, this doesn’t explain why “sending to ABC will be lost money” because if my interpretation was correct, the recipient could in fact spend funds at ABC using their private key. 
So what did I get wrong above?
Continuing…
I’m not sure what “publish ABC” means
Maybe it means: recipient shares their public key ABC with the sender (“publish ABC”), sender sends to “ABC+MyPubKey” and sends MyPubKey (of sender) to recipient. Recipient spends it so for anyone subsequently given or attempting to send again to ABC, the wallet can see it has been used and should not be re-used.
Is that it?
If so, how does the check work - what’s the way that anyone can lookup a receiving address and check if it is spent. I guess it is indexed in the spent book but it would be helpful to know more precisely.
So for every transaction the recipient must provide a new receiving address (public key) and the sender generates a DBC that can be spent by a key derived from the recipient and sender public keys?
Auditing and Tracking
For auditing supply everyone can check that a known amount has been transferred between two addresses, as explained above. But since no address is re-used it is not possible to track onward or historic flow of amounts, except by trying to match up special values of transactions.
For example, if 0.00000005395034343 is sent from A to B and subsequently the same amount is sent from P to Q, there’s a high probability that one entity owns B and P. But for differing or frequently used transaction values (e.g. .001) it becomes much harder to link them together.
The supply can be audited because anyone can look at the input and output values of every spent DBC in order to verify that the input and output totals match from any point back to the genesis DBC. Is that still the idea?
What is much harder is tying groups and chains of transactions together in order to deduce flows between different entities. So even if it becomes known that B belongs to Bill, because the owner of A discloses the identity of the recipient, it is not easy to link Bill to P without additional evidence or inferring this from co-incidental rare values as in the above example.
Simlilarity with BTC
Assuming BTC wallets always create a new receive address rather than re-using them then this seems essentially similar to tracing funds using the blockchain by analysing flows between addresses.
12 Likes
I don’t pretend to understand all the coding but isn’t there some way to code a verification method for a node to check if it left its data behind after joining? Similar to self authentication or something. I mean you don’t only have to verify who you are but also that you have the package you were supposed to be carrying. If you drop it along the way it doesn’t matter if your credentials are correct. So maybe there needs to be a mechnanism that compares “Do I still have my data? If yes then next step. If no copy from another node before proceeding and flag last step as a problem.” Or something like that.
3 Likes
Also I’m curious how all this fits into the roadmap. As the list of things to launch seems to get longer and more convoluted but the roadmap itself doesn’t get updated that often.
I’m not trying to pester just… eager to have my safe network and graphical interfaces help organize things.
3 Likes
Does a general strategy of sending “banknotes” make sense here?
I owe a bill of 172.12 SNT
I send ( or rather my wallet works it for me)
1 x 100
1 x 50
2 x 10
2 x 1
1 x 0.1
2 x 0.01 DBCs
4 Likes