I think this one probably deserves its own thread. It was one of the things I had noted down while reviewing the code, but wanted to dig in a bit deeper first.
It could be good to confirm the current behaviour. My understanding of transactions is:
For user transactions, the user owns the private keys for their user wallet, but requires the elders of the section storing the wallet to validate the transaction.
For section reward transactions, the elders own the private keys for the section wallet, store the section wallet and self-validate the transactions.
For 1, this means the elders can’t spend the user’s tokens, as they can’t fabricate the transaction history. This means the primary attack vector is likely to be double spends, where the attacker controls the user, along with the elders in the section where the wallet resides. I’ll ignore the complexity/feasibility of doing a double spend for now.
For 2, I’d like some confirmation on whether the assertions are true. If true, given elder nodes set the reward amount, colluding elders could potentially drain a section wallet.
Perhaps a layer of indirection for validation would resolve this, in a similar way to user wallets. Maybe elders should only be able to validate reward transactions from other sections. To put it another way, the section wallet is held in a different section. Given a section should only be creating reward transactions, the amounts could be checked during validation.
The section transaction flow would then be similar to a user transaction. To abuse rewards, an attacker would then need to control multiple sections, including both the reward requester and validator sections.
I’m piecing my way through this, so the above assertions and conclusions could be wrong. Perhaps @dirvine could chime in a little?
I think they were implementing this (i.e., the replicas of a section’s funds are held in another section) but I haven’t followed closely enough in recent weeks to know if this was merged. @oetyng will know.
To further secure the section funds, I wonder if the strategy of placing the replicas with the elders of another section can be expanded further with a randomness component like a threshold relay. For an example, see Dfinity’s random relay idea (starting on page 16). Essentially, the replicas of a section’s funds would actually be held by randomly selected elders not just in a different single section but in multiple different sections (e.g., up to 7 sections, with 1 randomly selected elder from each of these sections serving as the section fund’s 7 replicas). The strategy would certainly introduce several complications and is maybe not worth the trouble/complexity. A simpler version of the threshold relay idea to secure section funds would be to place the replicas with a randomly selected, larger set of adults of a certain age in both the section as well as in the sibling section.
Re: 2, someone at MAID please step in and correct this thread, but I thought it was For section reward transactions, the elders own the private keys for the section wallet, but another section stores the section wallet and validates the transactions
I just pulled the latest code from master and it looks like there are loads of changes relating to rewards and sections. So, it looks like I was looking at stale code. I’ll start looking at the new code. Thanks for heads up!
Elders own private key shares for a section wallet. That section wallet is stored on the network. In the initial stages, the chances of this being their own section are higher (1/1, 1/2, 1/4…) (edit: I see @dask already had this )
The elders validate the transaction, and must have a (super?)majority for this to go ahead. (? there as I’m not sure where we are exactly with this just now. Supermajority is coming in for some things. I believe it will be there fore transfers, but I don’t think it’s in just yet).
This is essentially the same for section/client wallets. The vairation is just about multi-sig aggregation (which eventually clients could perhaps do also).
@Traktion latest changes are around initialisation of section wallets, with new sections now starting a fresh wallet + balance (at some section, as above). Here we don’t need to transfer coins, so there’s less to trip up splits. (previously old section had to transfer to new section, and new section wait to verify this).
With a normal load of good nodes, doing any transfer from the “old” wallet should not be any more possible than all elders colluding to do a transfer in the first place. (Even so, there is talk of “freezing” old funds as a last act of a section… i’m unclear how necessary this is atm).
(At least I think that’s the logic there. @dirvine, @oetyng correct me if i’m wrong on any of this!)
All good, yes AT2 type transactions are all super majority now. We have gone super majority for all network BLS signatures as well for the moment. Room to optimise later.
Ok, so the (super) majority of elders can control the section wallet.
Ok, got it! Thanks.
Are there any differences between a section wallet and a regular user wallet? If there was a (super) majority of elders controlled by a single entity, could they then create transactions from that section wallet out-of-band, just as regular users can?
I’m just thinking that my initial thoughts were that rogue elders could manipulate the rewards for payments. However, it sounds like it may not be as difficult as that. If they can provide a sufficient majority of signatures, it sounds like they could initiate a transaction directly from the section wallet.
Of course, we could make the argument about multi-sig on any wallet, but the list of signatories would remain static. With elders and section wallets, new elders become signatories and the section wallet is likely to be well funded.
Presumably this is what @mav was concerned about originally and may still be the case?
Yep. I’m not sure it’s that easy though… You’re in a byzantine fault world there (I think). If bad actors can take a section they can take the coin/manipulate data (not necessarily read, but perhaps trigger deletes on eg), take money… ignore adults etc. It’s a bigger worry I think.
Yeh, i don’t think any of the recent changes would specifically address that concern.
This is not so bad, as owners sign updates then all bad actors can do is to not give the data back or give an old version. They cannot manipulate data.
The one caveat is the section wallet and we do need to further secure that over time.
What do you think of @mav’s idea to tie coin issuance to a certain network metrics like growth, the nuance being that drawing coins from the wallet isn’t controlled by just signatures but also a certain metric being reached by the network. (I’m probably not doing justice to the idea here; would need to find the post to better recall).
It has legs, the issue though is beyond just that oracle I think, I mean as a rouge section could also lie about the oracle and we cannot “see” it paying out. The ultimate would be the section wallet did not exist. That’s a nice problem to solve and I cannot wait to have a day or 2 to think about that.
It does feel like a problem that will shrink as the network grows though. More wallets with fewer tokens in them certainly makes an attack less rewarding.
Also, having the section wallet does provide the opportunity for a hybrid solution too. Perhaps there could be a mechanism that ensured section wallets only had enough for rewards, for example.
It seems like a decent platform to work from either way.
What if you resurrected a bit of classic safecoin? You could have 2^32 data objects (wallets) spread randomly in xor space that hold one SNT each. Elders would need to hunt for them and claim them so they could be used to spend or store SNT on behalf of the network.
Given that would essentially be mining, wouldn’t it nullify many of the claims of SNT and safe network efficiency?
I agree it is doable, though. Maybe there is another way, which can lock tokens until a defined number of splits have been completed though or some such?
EDIT: If it was enormously hard to find the ‘treasure’ by brute force (read: uneconomical), then this would actually be a great idea, imo. That is, if it is trivial to accidentally ‘stumble over’ the treasure, but near impossible to search for it, this would be excellent.
Actually when i thought of what @jlpell wrote first off, one way is to have 2^32 units (or any number that is quick) and when a section goes below one token worth (actual one unit of tokens worth) then it selects the next unused unit. The section has to request it from the section that controls that units XOR address. That way there could be some checks and balances designed into the process.
To make things quicker maybe 10 tokens per unit.
Now the issue is how to find the next unit that is unused? Maybe some algorithm could be devised to make this quick. Maybe each section can keep a bitmap of available units and its updated in a lazy manner.
The benefit would be in the check and balances that could be devised.
EDIT:
But still I think if the coin balance that a section uses belongs in a random section (due to xor addressing) then this also allows check and balances, which is likely to be sufficent. And the amount a section controls has a maximum of nominally 2^32/#sections.
What @jlpell idea does if I read it correctly chops up the amounts into many balances (I suggest initial size of 100 tokens per unit) and causes that check and balance to occur every time a unit is claimed and also whenever the balance the section controls is used.
Also how a unit is refilled and made “unused” also has to be considered when a section’s balance grows to over 2 units worth
I suppose my fear was that it would cause people to go brute force searching the xorspace for them, which could put a substantial load on the network. It would also use a lot of energy, which is one of the criticisms of blockchains that this token hoped to avoid. I do like it otherwise though.
I was pondering it a little more:
If section rewards only come from PUTs after the first split, then there is no need for a section to have a large wallet balance.
If anyone can take part in the search for unclaimed tokens (treasure hunt?), then it doesn’t just fall to farmers to find them.
There is a network speed limit in terms of how quickly xorspace can be searched. No amount of brute force on the client side will change this, which does equalise the playing field. Bandwidth to perform the GET is unlikely to be hard on the client either.
Burying the treasure at genesis time would seem feasible, although it would be hard to prove it was random/unknown by the node owner.
If the treasure was actually only a pointer to the real location, which required some ‘work’ client side to derive the pointer target, it would shift the load back onto the client.
The more treasure hunters, the more treasure will be found. This seems to be the inverse of what would be desirable, in terms of money supply. Perhaps some sort of ‘clues’ can be provided to help find waves of treasure (much like difficulty on blockchains). E.g. a range of xorspace to search could be provided, with the range getting broader for each treasure wallet (until it is unbound).
Depending how it’s done, I don’t think this is really mining. If it’s just a mindless repeated lookup of xorspace detached from ‘real’ network activity then yeah, that would be like mining and wouldn’t be so good. But if the search happens in tandem with meaningful network activity then it can be a way to add incentive to those activities.
It’s probably better to make the treasure hunt for the authority to claim the reward rather than a treasure hunt for the location of the reward. Maybe these two might end up related anyhow, but I don’t see any need for them to necessarily be connected.
I feel it is feasible to prove it’s random/unknown. I won’t go into details since it diverges quickly depending on whether we’re talking about searching for names vs searching for authority to spend, but we can use a similar idea to how each bitcoin block depends on the prior one, so there’s no way to ‘jump the queue’ easily, making only the current treasure ‘known’ and all future treasure ‘unknown’.
Overall I feel like most of the ideas in this topic about rewards are heading in a very positive direction. Good to see these ideas taking shape.
)