Did you try
$ ./wipe_wallet_and_spendbook_data.sh
4 Likes
Will try later, will probably work better than reinstall 
Btw everything in @danda code works pretty elegant, I’m just trying 2 look @ the edge cases… When users loose [b]earer Cert… or whatever other scenario might pop up.
Send from Alice to Bob work as intended, it’s just when I started messing around… trying to reissue issue_genesis with Carol and multiple [b]earer Cert that errors predictably started showing up… 
Oooh yeah what’s actually the logic in trying to send [o]wned to a [b]earer pubkey?
It can become a funny game, in which people can (send money/check the balance) to a [b]earer pubkey they all know and eventually one of them drains it and the insanity 
starts all over again. 
Sorta like lottery with no middlewoman 
4 Likes
@danda I have a question which I gather the answer will be no, but I wonder.
Is it possible to “find” any DBCs sent to your public key that you did not know about or lost the “link” to it?
5 Likes
awesome bdc playground!!! <3 you super ants
4 Likes
hi @19eddyjohn75. I tried to recreate your scenario, but it’s working fine here so far. I can reissue an owned DBC to a bearer pubkey without error.
It sounds like your wallet somehow got out of sync with your spentbooks. Please stop all processes (spentbooks and wallets) and run wipe_wallet_and_spendbook_data.sh. Then, if you can re-create the scenario, please post it here, with all commands starting from a clean (wiped) state.
Here I tried (from a clean state):
>> issue_genesis
Attempting to issue the Genesis Dbc...
>> keys
-- Wallet Keys --
84947e6c2f43ae9404ff0942d041f8a87a16b11a3d4475d5c0c5e84acd719a1e892d0486cfc0be4ddb4d38ae8a3b8510
>> reissue
Available balance: 18446744073709551615
Amount to spend: 1000
[b]earer or [o]wned: b
-- Begin DBC --
...
-- End DBC --
note: this DBC is bearer and has been deposited to our wallet
note: DBC written to file 637144361.dbc
note: change DBC deposited to our wallet.
>> keys
-- Wallet Keys --
84947e6c2f43ae9404ff0942d041f8a87a16b11a3d4475d5c0c5e84acd719a1e892d0486cfc0be4ddb4d38ae8a3b8510
851ab15b7b471b2087254777016673038e8ded7cc1d8cde9b11ee0aa8adc3a31fa40660e77d3a180b7b2706933004451
a5b58b0b41e1edaadec066329648f16fe6268458c7e99d085cce0e707b64bbe2654bce38fc650f39a0c52660f7c61c74
>> reissue
Available balance: 18446744073709551615
Amount to spend: 5000
[b]earer or [o]wned: o
Recipient's public key: 851ab15b7b471b2087254777016673038e8ded7cc1d8cde9b11ee0aa8adc3a31fa40660e77d3a180b7b2706933004451
-- Begin DBC --
...
-- End DBC --
note: this DBC is 'mine' and has been deposited to our wallet
note: DBC written to file 2358641530.dbc
note: change DBC deposited to our wallet.
9 Likes
There’s nothing special about sending to a bearer pubkey really.
A bearer DBC includes both the SecretKey and PublicKey inside the DBC. So anyone in possession of it has the SecretKey and can spent it.
An owned DBC includes only the PublicKey. So only the recipient has the SecretKey, and only they can spend it.
One can reissue to a given PublicKey any number of times. So there shouldn’t be any problem with reissuing to any PublicKey.
An interesting technical detail is that the spentbook nodes never see the PublicKey that is used in the wallet. Instead, a one-time-use key is generated. This is similar to a “stealth address” in Monero and is a privacy/fungibility feature. This mechanism allows one to eg post a donation address on a website, and receive multiple payments to it, but each payment uses a unique key in the public spentbook (ledger).
14 Likes
Ok, a couple things to understand about this:
-
Unlike blockchain systems, our core DBC system (spentbook) does not keep track of unspent DBCs. There is no “utxo set” equivalent. So when Alice reissues and creates a DBC owned by Bob, it is up to Alice to actually transmit that DBC to Bob, and then Bob may hold it and eventually reissue. The sample wallet implements a
Depositcommand. This is a strictly wallet (client-side) feature to enable Bob to keep track of his received DBCs and make them known to the wallet for spending. -
We realize that “Sender must somehow send a DBC to Recipient” is kind of vague for a payment system.
So the Safe Network will implement a standard, built-in way of doing this – as a layer above the core DBC system. Such that Bob’s wallet will have a kind of Inbox that senders can deposit DBC into without Bob having to do anything. But the cool thing is that it should always be possible to send via alternative (even offline) ways as well.
Ok, so given this understanding. If one is using the “built-in” way of sending, it should never get lost. But if one uses some alternate method, it could get lost. Just as cash can get lost, or a paper check. So that’s kind of a with great power comes great responsibility kind of thing.
21 Likes
Good god, this is what I get for being busy on a Thursday. DBC playground and core pieces integrated and passing tests? Time to get back on to the forum more regularly. Can’t wait to play.
13 Likes
https://www.codedump.xyz/properties/Ykduoh_zL8nnZY-E
https://www.codedump.xyz/yml/YkduQh_zL8nnZY-D
- The first error is because I try to reissue issue_genesis after I did it with the Alice account
I also cargo run --bin wallet for the Carol account - The second error is due to trying a nonsense ip.port
Spentbook peer [ip:port]: 127.0.0.1:5299 - Third error is trying to send an [o]wned spend to the [b]earer pubkey
Recipient’s public key: 3054eff96bdd680fb5c6dad3b5c71b3d898e13f85576dc1a62feb20bed28aa818b7aa94f472fbfff8ab9df86cbd6f4ed - Fourth error nodes went offline
× recv.next() returned None
The recreation is a little bit off, because 
and hyper happiness to be on the DBC playground fueled my actions yesterday. I hope true hackers and code reviewers can find errors beyond the scope of a clueless consumer 
Thx 4 coding this up and keep up the great work 
6 Likes
Auditability (the total number of SNT) is possible? Thx @danda
1 Like
yes, because:
-
The total supply is “minted” in the genesis DBC. There is no ongoing issuance contemplated in the core system. (however, issued DBC will likely be placed into a “lockbox” and farmed into circulation by a higher layer, exact design TBD.)
-
Given (1) all we have to do is is iterate** over all historic Tx and verify that the sum of input commitments >= the sum of output commitments (and no negative values, checked by bulletproofs). So long as that is valid (and the cryptography is solid) then the supply has not been inflated.
** Iterating over all the tx in an ordered fashion is not exactly trivial in a sharded, decentralized, dag system. @davidrusu has recently put forth a design for that.
The key thing though is that it is possible. We contemplate there will be some special auditing nodes that consolidate entries from all sections/shards and perform this function.
11 Likes
yeah, that’s a good thing to try. The spentbook returns an Error if any Dbc is attempted to be double-spent, including the Genesis DBC.
>> reissue
Available balance: 15
Amount to spend: 10
[b]earer or [o]wned: o
Recipient's public key: 3054eff96bdd680fb5c6dad3b5c71b3d898e13f85576dc1a62feb20bed28aa818b7aa94f472fbfff8ab9df86cbd6f4ed
Error:
× Invalid bytes representation.`
Ok, so it can’t read the pubkey for some reason. I’m unclear how you obtained this (pubkey?) exactly. Can you also post the output of the other wallet?
seems you found a real bug there. 
good work! I will try and recreate when I have a chance.
9 Likes
Thank you, that is what I thought would happen, it gets lost. And of course over time there will be some lost, due to lost accounts, lost passwords to accounts, and people sending DBCs to unused IDs. I know this will not be an issue with how ever many decimal places used in specifying value.
So my understanding is that the DBC is a piece of data on the network. Is that correct?
Will DBCs have a unique tag (or are 64 bit tags no longer used)?. These have not been mentioned for a long time that I’ve seen noticed. It was 64 bit tag and 256 bit address. Tags were to categorise the data with reserved tags and non-reserved tags. For example the old safe coin would have a reserved tag number only used for the 4 billion safe coin data items.
Is this so that only 10% issued to MAID exchange and 5% reserved for investors leaving 85% pool as per original papers.
OR are we talking of something different here?
I gather it is not possible to find *your* DBCs this way since the public key of receiver is not visible/known when looking at the DBC
5 Likes
It could be looked at that way yes. However an unspent DBC could just be sitting on a piece of paper in your filing cabinet without ever having travelled across the network.
There is no provision for tags currently. Certainly not in the public spentbook as anything that distinguishes one dbc from another harms fungibility. Wallets could possibly attach metadata when transferring DBCs between parties. That would be at the payments layer, one level above the core DBC system.
It could be used for that purpose. But the primary purpose I am talking about is releasing “new” coins into circulation over an algorithmically determined schedule. Anyway, the lockbox idea has been discussed but is not decided, so it’s just a possibility for now.
One should normally not need to “find” your DBC, because it would be delivered directly to your wallet inbox (or otherwise delivered). Just like one does not need to find cash or a check that someone deposits into your bank account or into your mailbox.
5 Likes
Ah I’ve been misunderstood, and easy to do.
Originally a chunk address was
+-----------+--------------------------+
| tag type | (chunk hash) XOR address |
+-----------+--------------------------+
And may I am calling it wrong as a tag. Its been a while since I noticed it used.
Using tag would not create any identifying info other than identifying this data chunk as a DBC type
Well those coins have to come from a pool (locked box) and in the original papers there was the 80 or 85% to be in the pool and released as rewards were given out. This allowed the framing rate to be mostly disconnected from the PUT cost which allowed for the network to have better controls over what to charge and what to pay out.
Now are you meaning there to be more than the 2^32 (approx 4 billion) SNTs?
Thats a given. Its more a question from previous and a hypothetical question as to what is possible.
4 Likes
Hi @danda
All [o]wned DBC’s start with 01000000 followed by the pubkey 9448908a69eb130114681150fe8e82d5300972db30166fd93a963aeb33856ca98323be1e32a13f4b29b3f32bab640395
which is 96 characters
010000009448908a69eb130114681150fe8e82d5300972db30166fd93a963aeb33856ca98323be1e32a13f4b29b3f32bab640395
Assuming that maybe all [b]earer DBC’s have a 96 characters pubkey, but obviously in this case they start with 00000000 (wonder where the privatekey part starts, if @ all incorporated?)
000000003054eff96bdd680fb5c6dad3b5c71b3d898e13f85576dc1a62feb20bed28aa818b7aa94f472fbfff8ab9df86cbd6f4ed
I didn’t really look into this anymore, cluelessly assuming an “Invalid bytes representation” would have no output. This honestly gets over my head… probably reproducible with the [b]earer pubkey.
Maybe this will show up when the nodes are offline, but your still trying to reissue a DBC.
I’m a little bit puzzled by these events, I go from having 1638 to 653 DBC (the 3 little 
are not offline)
balance
Available balance: 1638
unspent
– Unspent Dbcs –
a676ba06a906fcda962c58f0b7069fedc895eab45c42bee32467a8c8a94574f1, rcvd: 2022-04-02T06:22:31.848949748+00:00, amount: 985 (mine)
acf861c725aa4f6cb5f0667f743554219707ae10a550142956b47c3a96ee89d9, rcvd: 2022-04-02T06:47:07.058319595+00:00, amount: 23 (bearer)
f019a8dd7d37cbf7ab2c1e34bb5a3425c98aba5c7fecea7934fa8d2964063235, rcvd: 2022-04-02T06:23:34.060795486+00:00, amount: 615 (bearer)
f5c14848cdc44f47ea33c934d3aac75dbb2526740741e81db5c6921274ce210d, rcvd: 2022-04-02T06:20:29.493150818+00:00, amount: 15 (mine)
reissue
Available balance: 1638
Amount to spend: 1638
[b]earer or [o]wned: b
Error:
× Dbc error: Key image has already been spent
╰─▶ Key image has already been spent
reissue
Available balance: 653
Amount to spend: 653
[b]earer or [o]wned: b
Error:
× Dbc error: Key image has already been spent
╰─▶ Key image has already been spent
reissue
Available balance: 653
Amount to spend: 653
[b]earer or [o]wned: o
Recipient’s public key: a676ba06a906fcda962c58f0b7069fedc895eab45c42bee32467a8c8a94574f1
thread ‘main’ panicked at ‘source slice length (32) does not match destination slice length (48)’, src/bin/wallet.rs:392:31
note: run withRUST_BACKTRACE=1environment variable to display a backtrace
eddy@hal9000:~/sn_dbc_examples$
3 Likes
There was just a slight misunderstanding there. This is what was meant.
So, in case that design would be chosen, the “new” (unlocked) tokens come from the pool where the vast majority of the initial total supply of already minted DBCs, is locked to start with.
If we wanted to go back to the recirculation design, some part of data payments could be DBCs that are placed into new lockboxes, thus re-filling the pool.
The needs at the time would be evaluated by the Elders who decide the proportion.
If the unlock rate is deterministic, then having the Elders decide the rate of flow back to the pool, is equivalent to deciding how much is net-released from the pool into the economy.
Explanation:
If base case is that payments should always go to pool at equal rate of the continuous unlocking, - that then gives a base case of no net-release. The circulated amount of tokens is constant (over time).
Then, every token that the Elders decide should go to node operators instead of to pool, results in a net-release into the economy.
This means the Elders can measure network health and dynamically adjust net-release even when the unlocking algorithm is deterministic.
The big question is what the locks look like, i.e. how are they unlocked etc.
With the above recirculation, the ideal would be to have it randomly accessible by node operator secret keys, but with higher probability proportional to node age.
9 Likes
That is what I understood that to mean. My question was more related to whether the design is for the previous concept of issuing SNT on a 1:1 exchange for MAID. Or if this was something new on top of issuing all SNT to people initially.
I found out from @danda that its the 4 billion as initially and as you just explained
I wasn’t thinking of this as that was pretty much removed with the introduction of DBCs
That is interesting.
I had thought that the idea was to issue all SNT so that the network sections were not holding large reserves (“locked boxes”)
But I gather then this maybe on the table for consideration.
Be interesting to see the final outcome of these considerations and what will work best and securely for the network.
5 Likes
Lockboxes is a different idea, distinct from the one where current holders of MAID become holders of full supply of SNT.
The latter would be the simplest and most secure way I say. But there would be a few whales holding most of the supply then.
With quite recent numbers: 6,6% of addresses (not persons…) holding 90% of tokens, 30% holding 99%. Such numbers.
Pro’s and cons though. That kind of absolute simplicity amd security is worth a lot…
Lockboxes is a whole world of complexity added. And security is harder to verify as complexity grows.
Not that I know how everyone else imagines this but I would see it as essential that the lockboxes are not controlled by the sections. Held as data yes, but not more than that.
The way tokens were held in sections before, we just required a super-majority of Elders in that section to spend it all. If that was section #1 that meant all of it. If one after 2 splits, then 1/4 of all. Really bad.
The lockboxes is something else (exactly what I do not know, and I don’t know how feasible). It will require for example some puzzle solving, cpu cycles… to unlock.
And it’s not Elders who will unlock them, but anyone who can. (Although, within the above described idea, ideal would be for random node operators to be able to unlock, with probability proportional to age…).
What Elders can do in the above idea, is to partition the stream of data payments between the pool and the nodes in the section. So they do not control large amounts at any point in time, just the ratio of the stream of payments going to the pool and/or the nodes in the section.
They do so that by telling the paying client what ratio they will accept as payment for the data. The client makes the payment to nodes and the locking to pool. So the Elders never control the pool. They can’t spend from it.
So, above is assuming many things and we’ll have to see what the limitations are in reality.
But if I were to toss some ideas, that would be one initial angle.
10 Likes
I tried to say this in what I said and obviously failed. I agree all that and was my understanding. Thankyou for clarifying it.
Ah OK, good.
An issue I have with this is the old one of how much work is enough? If you make it so any device that can be a node can do this, then you go from a SBC that can do say “X” amount of work per second to a consumer level threadripper that can do “100X” to “1000X” amount of work per second. And trying to match work to the device is also a problem since I can make my threadripper look like a low power/speed 2 core processor on a SBC.
I hope they do not use this route.
What would be better is retrieving data from multiple place and doing basic work to unlock is better. The time for retrieval evens out the fast/slow processor problem.
Sounds good.
Interesting to say the least. It is an important area to do well and I’ll be interested in what the team finally come up with.
2 Likes