5-(B) - Security issue of coins



  • Having to move your coins to vote, this might cause a higher risk to loose them by accident. We should find a way to allow the “voting coins” to reside in their individual “safe” storage condition, while still be able to express their voting power.



  • how about votes calculated by amount of time/blocks staked. say every 7 days worth of blocks that your are online staking aka supporting the network you earn 1 point = 1 vote. then large whales would have no advantage over smaller holders.

    The reason I propose this is because you would need to earn your right to vote by securing the network and your voting capacity would be limited by the amount of time spent securing network instead of the amount of weight securing the network.

    right now I could hold my coins on an exchange if I see something I want to vote on I just move my coins over wait for the allocated hours to pass before I can vote(I think same waiting time as to stake) and then I can vote on everything flagged. If voting rights was determined by time staking and a set amount of votes allocated for that time frame and those rights reset every time a certain % of coins moved from wallet (eg 50%) it would be much more time consuming for a bad actor(most probably a large holder) to manipulate the voting process.

    I think votes should be earned by supporting network and I think only nodes who actively secure network should have voting rights.



  • Staking Voting sounds interesting. I also have something similar in mind, since the owned staking rewards over a certain period typically would correspond closely to the real distribution of the overall staking coins during this period. If the owner of the staking rewards would accept to have their reward coins locked for this certain period of time, you could use only those limited number of locked reward coins for voting at the end of that period, while the principal underlaying larger number of staking coins are free to spend or to move.



  • @dadon
    I’m with you in supporting the rights of smaller holders, but I see a problem in preventing larger holders to split up their coins onto many smaller addresses. Also the big bag holders should be the one with the biggest interest in a succesfull project enhancement, because they potentially would loose the most. So it’s reasonable to give whales proportional more voting rights (meant are votings on community proposals and not the one for flagging items).

    From my point of view, the current voting procedures definitely needs to be reworked. E.g. @btmr mentioned small transactions being done from larger wave addresses for realizing airdrops at the wavesplatform. I really think we could do it similar e.g. by using our staking rewards, or maybe even only a fraction of the staking rewards, for voting.

    Also, I wouldn’t leave it to every proposer when he likes to start the voting. Predefined voting periods where several votings will take place in parallel, should also reduce the effort for voting. It’s also less probable to forget a voting, since you may already know in advance when the next voting period will begin and you can then “prepare” yourself.

    Another feature we might take into consideration, is to delegate the voting power. Let’s say you leave your coins staking on a pool and you might want to delegate your voting power to the pool owner. E.g. when voting on technical aspects of future project development, the technical knowledge of pool owners is often better than the one of a typical marketplace user.

    @letsparty and @enum4_el1sh both refered to Decred which already has established a well elaborated governance system.

    Overall, we should eliminate the need that any coins would have to be moved for voting purposes. Since staking is a way for securing the network, I think it might be acceptable to limit the voting power on those coins that are publicly staking. Coins held on anon addresses thus wouldn’t generate any voting power.



  • @dadon @Pancake

    There are several good ideas and valid concerns here, so I would like to try my hand at this as well, maybe marrying the thoughts above in a in a happy wedding.

    Problem

    How can we achieve a fair distribution of “voting power” that

    A: gives power to everyone who is securing or supporting the network,
    B: respects the amount of individual investment in the network,
    C: prevents a single entity from controlling the outcome of voting, regardless of the size of their individual investment?

    Discussion (sorry folks, it’s long)

    A:
    The main argument in here is that the individuals who secure the network by staking should be the ones to have voting power. That’s reasonable but it also assumes that staking your coins and running a node is the only way to support the network and help it prosper. And that’s not quite true.
    Just check our Discord history for evidence: It’s littered with comments on the lack of adoption of the marketplace (“If only we had more vendors!”) and a lack of action on exchanges (“If only we got listed on Binance!”). Without people just using the network for what it’s there to do, what’s the point? Without people getting on bittrex, buying and selling some part now and then, where’s the liquidity that a currency requires?
    My point is this: there are ways to support the well-being of the network besides staking and this should be acknowledged in voting too.

    B:
    I agree that everyone who is running a staking node is especially invested in the network: it costs time and effort to install and maintain a node (in the case of staking via Particl Desktop it’s less effort and more electricity costs, but still) and more than that, it’s a commitment to lock the coins for a prolonged amount of time.
    At the same time, who is to say that marketplace-vendors with inevitably fluctuating wallet balances are less valuable to the network? They are the ones who will generate transaction and market fees for the staking nodes to receive!
    My point is: There are different ways to be invested in particl and therefore we need to differentiate our distribution and calculation of voting power accordingly.

    C:
    Ok, that’s probably above my head, LOL.
    Approaching this naively, I’d say there is either grading or capping the voting weight. With grading, we would apply a weighting curve that would predominantly reduce the voting power of very large “wallets”. With capping, we would just set a maximum amount of voting power an address with a balance can have. Now, this still leaves the possibility to just distribute one’s holdings across multiple addresses and then vote for each address. Again I will take up @dadon’s idea to impose restrictions on moving coins around addresses, which would make gaming the system at least time consuming and uncomfortable.

    Suggestion (ugh, just as long)

    A:
    Voting power should go to the active security providers of the networks, i.e. the individuals running a staking node, but also to anyone holding part in a wallet for a considerable amount of time. The latter reflects that users of the marketplace (vendors, customers) or liquidity providers (traders) are supporting the network as well.

    B:
    The majority of the total voting power (say 65%) should be distributed to active staking nodes.
    Here is where I happily take @dadon’s great idea and @Pancake’s spin on it:
    Let’s calculate individual voting weight by counting the staking rewards over a certain amount of time and dividing them by the total amount of network staking rewards during that time. I guess we should track a one month or even longer. Otherwise we will not have fixed the problem of being able to quickly buy some part and vote.
    The remaining voting power (35%) would then be distributed across any non-exchange-addresses. Here, the individual voting power for an address would be calculated by averaging the amount of part held over a certain amount of time (e.g. one month).

    I would tie a vote to a transaction that requires a small amount of part. This would make it more inconvenient to abuse or game the system. By having a little barrier, we enforce votes by honestly interested parties.

    Subscribers to staking pools would delegate their power to the pool owner. Good pools would be those who are transparent or democratic in their use of voting power.

    C:
    Take a grading curve and make sure that very large token weights get reduced while very small weights gain a little. This way the “individual voice” doesn’t get lost, while large holders still keep their influence.
    In order to keep large holders from simply distributing their coins across multiple addresses and voting through each of them, enforce rules that declare such addresses illegitimate for voting:
    addresses that changed their balance by a significant amount within a short period of time,
    addresses that have been created less than a month before the vote,
    and so on.

    Cheers

    Note: edited in places where I meant “addresses” but had written “wallets” before



  • Hi @btmr
    sorry it took me a while to respond to your great discussion points and valuable suggestions. Also long text is welcome 😉
    I know from my own messages that the text often get longer and longer, but I think it’s important, because otherwise often it’s not becoming clear what the writer exactly wants to point to. Probably this post also won’t become a short one lol

    Before I comment on A - C, I’d like to make aware of a fact I didn’t knew before. In a short discord chat with Arnold, he mentioned that voting is currently done off-chain and not on-chain. I think this is an important point and I am convinced that for governance and general voting purposes (as we discus here) we necessarily need on-chain voting. If I understand correctly, the marketplace will be only one of multiple dApps which finally will make use of the particl network and of the particl coin. Since there might be other dApps as well, it would become a problem if votings for the whole particl-network would only take place at one specific dApp (like here the marketplace dApp).
    When we assume that voting will finally be done on-chain, this might have as consequence that for voting only the publicly visible data on the ledger can be taken into account. I’m not a dev, but I guess this would mean that voting could only be done based on the addresses and their balances or maybe the balances history. I don’t think that any wallet information can be linked to. That’s also the reason why default wallets currently (with off-chain-voting) can’t vote on proposals because they are for security reasons treated as a separate wallet and thus shouldn’t be linked in any way to the marketplace wallet. (That’s what I mean having understood so far. Please correct me anybody if I’m wrong)

    Now to your suggestions:
    A:
    I see your point, but I see technical problems to calculate the time a wallet holds a certain amount of coins. Remember we might have to go with on-chain voting and later on other dApps might make use of the particl network as well.
    I am not convinced to give liquidity providers (traders) specific voting rights.The traders rely on a secure network which is rather been guaranteed by the stakers. Traders might also have contrary interests than the stakers. E.g. they might be interested in a rather high price volatility or maybe some of them might think of making profit out of double spends. That’s why I wouldn’t specifically consider traders important for voting on governance issues. However I would also love to give sellers and buyers more voting power. What do you think of discussion point 10-(M)? Would this be a kind of possibility? Having e.g. the top marketplace sellers to express their preference for one voting option and by that “influencing” the later voting outcome. (I hope it becomes clear what I mean)

    B:
    As described in A, it might be difficult to calculate the average balance of an entire wallet with on-chain voting. Maybe there’s a way to calculate the number of blocks non-staking UTXOs are holding a certain balance. But this would mean any addresses will receive voting power, also those addresses where exchanges are holding balances as custody. I don’t think there’s an easy way to destribute the remaining 35% voting power in a fair manner.
    However, I also can imagine to vote by transacting small amount of parts. Delegating voting rights to pool owners would also be a perfect way to increase the voting participation of small bag owners and thus would be a way to reduce the impact of big bag owners on the overall voting results (see also C:)

    C:
    I love your idea of a grading curve.
    However, I still don’t know how to prevent larger bag holders from splitting up their coins. Again, this has been said with the assumtion we’d like to go with on-chain voting and everything is based on public addresses and their balances.

    What are your thoughts in terms of off-chain / on-chain voting?



  • @Pancake
    Both onchain- and offchain-voting have their merits.
    I believe (but I need to check) that Decred, which was mentioned above, has both:
    offchain-voting for general proposals and onchain-voting for things that concern algorithm changes like block time etc.
    This, I think, comes from Decred having both POS (stakers, holders) and POW (miners) and thus two parties with different interests.
    With that in mind, I don’t think offchain-voting is inferior to onchain-voting. It’s about how it’s implemented and what it’s used for.

    For the community-proposal stuff that we have (“Let’s change the text on the website” etc.), offchain-voting is probably better because it’s less of a headache.

    Yeah, the bit about traders…it’s just my way of saying that we should not only focus on staking nodes. You’re right that for network-governance, they should have no say. But if someone puts up a proposal “HitBTC sucks. Let’ get off HitBTC immediately”, people who trade part there might want to have a voice.



  • @btmr said in 5-(B) - Security issue of coins:

    As for onchain-voting:
    Why would wallet statistics like calculating an averaged balance be a problem? As long as we are talking public balances, all the info is right there on the chain.

    From my understanding, only public addresses and their balances are visible on the blockchain, but not the underlaying wallets. If I have 500 part and send 100 part from my wallet to another address on the same wallet, it’s only me knowing that the balance of my wallet hasn’t changed. An external observer couldn’t say for sure that the 100 part still belong together with my remaining other 400 part.

    Any restrictions we would try to apply on certain wallets will only be applicable within the wallets, and others can’t check whether certain wallets apply those restrictions in a correct way. You know what I mean?

    I’m not having a large technical background on that, so maybe I’m also wrong, but that’s where my doubts are coming from.



  • @Pancake
    Ahh, now I know where the confusion comes from:
    I was just too sloppy in my writing: I was always thinking of “addresses” but more often than not wrote “wallets” and that’s what made you scratch your head for good reason!

    You are right: you can’t apply these restrictions or calculations to wallets, since no one but the keeper of the seed/private key knows which addresses belong to a wallet.
    But you can do that for addresses and that’s what I was thinking of.

    I will edit my posts accordingly.
    Sorry for the confusion. My bad.



  • @btmr
    🙂 ok, now it gets clear.
    Thanks for all your feedback. So I will try to write a short summary in the next days. 👍



  • @btmr
    For your 35% votings on public addresses I still have two more questions which came up.

    • You once mentioned “non-exchange” addresses. Do you mean addresses from exchanges like Bittrex where they hold coins for custody shouldn’t have voting rights? If so, how should one distinguish exchange addresses from normal investors addresses?

    • How can you distinguish addresses which are staking from those that doesn’t stake? Is this becoming clearly visible on the blockchain? I guess you can see when an address receives a staking rewards. But do you also see when the address is staking on a pool, and also if an address stopped staking its coins? Otherwise those staking addresses would have the possibility to vote twice. (First with their stakes, second with their public balance on their address)



  • sorry only just seeing this now! there is a lot to think about here let me read over it in detail so I can give a worthwhile opinion.



  • @Pancake
    Regarding “non-exchange” addresses:
    Yeah, that’s what I meant. In principle, there is no way to discern these addresses, as far as I understand.
    The difference is this: For exchange addresses, you don’t hold the private key and therefore cannot sign transactions yourself. So if we require to sign an outgoing transaction with the private key in order to vote, that would exclude exchange addresses.
    By the way, this is just me spitballing amateur ideas! Don’t know if it is really feasible like that.

    Regarding the staking addresses:
    Yes, I just thought of looking at which addresses are getting stakes. This is why I said that for staking pools, the participants delegate their voting power to the pool owner: because the pool owner is the one that is technically staking.



  • @btmr said in 5-(B) - Security issue of coins:

    The difference is this: For exchange addresses, you don’t hold the private key and therefore cannot sign transactions yourself. So if we require to sign an outgoing transaction with the private key in order to vote, that would exclude exchange addresses.

    Since the exchanges own the private keys, how could we prevent them to take part in the votings. They just might get to powerful. However, this would probably be the same when they also stake their “custody” coins. But at least Bittrex doesn’t stake its coins so far.

    I like the idea of delegating voting to pool owners and voting by an outgoing transaction. I am also just an blockchain amateur, but it’s always interesting in discussing whether the own understanding of blockchain is more or less correct or rather wrong.

    I think looking at addresses which getting stakes might also be not as easy. If an address received for two month stakes and the last month no stakes anymore. How shoud we rate this? Does anybody has an idea how to “calculate” this in a fair way?



  • @Pancake said in 5-(B) - Security issue of coins:

    I think looking at addresses which getting stakes might also be not as easy. If an address received for two month stakes and the last month no stakes anymore. How shoud we rate this? Does anybody has an idea how to “calculate” this in a fair way?

    @btmr
    I think I can suggest a solution therefore. We don’t dicern between staking and non-staking addresses, but we just take into account the staking addresses “twice”. We do consider their vote based on their received staking rewards and also consider their vote based on their average coin balance together with all the non-staking addresses which doesn’t receive any coin rewards. Then we calculate the final votes by 1/3 of reward votings and 2/3 of coin balance votings. Because the “staking” addresses take part in both votings, their overall weight on the voting results are 2/3 (or close to 65%) and the overall weight of the non-staking addresses would be 1/3 (or close to 35%).

    I made a sheet with some sample calculations for different addresses. Addresses A1 and A2 would vote for Option A and addresses B1 and B2 would vote for option B. Addresses A1 and B1 are staking addresses and their staking rewards will take part in the reward votings as well.
    Simulation_Reward+CoinBalance-Voting.jpg

    I think this would be an appropriate way to calculate votes based on any outgoing transaction from any address. However, I also see another “problem”. If you’re voting by outgoing transactions and are taken only into account the average coin balance over a longer period of time, then only those addresses are taken into account from which this transaction is coming. If you’re a seller/trader you maybe will use for anonymity reasons for every incoming transaction new addresses. So for taking into account their average coin balance (also when the balance at time of voting is meanwhile 0) the seller/trader would also make an outgoing transaction from all his “older” addresses. You know what I mean?

    So maybe it would be better to use a defined Block-Hight where the actual balances of every address which made an outgoing transaction vote would taken into account for the coin balance voting.

    So a sample proceeding could be illustrated as follows:
    Accumulation+Voting-Period.jpg

    The “Accumulation Period” for the staking rewards would practically be rather in the range of 40.000 blocks (approx. 2 months) and the “Voting Period” (when you make your outgoing transaction) rather in the range of 10.000 blocks (approx. 1-2 weeks).

    On top of it, we could also apply a kind of “grading curve” to the voting calculation, so that big bag holders can’t easily dominate the voting, while holder of smaller amount of coins get slightly increased their voting power.

    So what’s everyones opinion on that?
    Feedback is highly appreciated 🙂



  • @Pancake
    Since the exchanges own the private keys, how could we prevent them to take part in the votings. They just might get to powerful. However, this would probably be the same when they also stake their “custody” coins.
    Haven’t thought that far yet but here is my opinion at least:
    Say you got xxx part on Bittrex, on an address they gave you.
    If an outgoing transaction is required in order to participate in voting, Bittrex would have to transfer some amount from that address without your consent. While they could do that, since they own the private key, why would they?
    That would ruin your trust in them and therefore their business model.
    An exchange can do all kinds of stuff with your coins but they don’t because otherwise they will lose you.
    So I see this more of a technical discussion in which exchanges would need to agree to not abuse your account.

    If an address received for two month stakes and the last month no stakes anymore. How shoud we rate this?

    I think I can suggest a solution therefore

    I think (hope) we arrived at the same thing, really:

    I proposed the 65/35 % split and calculation of the 65 % based on staking rewards. This implies that we have to look at an address and check both the amount of staking rewards and balance over a certain amount of time (when I talked about “differentiating”, this is what I had in mind).
    So first we check to sums: “sum of staking rewards over time t” and “sum of total balance* over time t”.
    Then we calculate the two corresponding percentages: percentage of the total network staking rewards and percentage of total network balance.
    Finally, we weigh the staking percentage with 65 % and the balance percentage with 35 %.

    In the end, I think this is basically what you are suggesting. Right?

    *here one can discuss if the staking rewards over t should be excluded from that number or not

    Regarding multiple addresses and voting by transaction, my position is:
    If you use many different addresses for privacy reasons or whatever, you simply will have to go the extra mile and vote for each of those addresses. Not convenient, I agree, but I think it’s a necessary inconvenience.
    You can always have your main stash on one address and a few smaller “operative” balances that don’t affect your voting power too much.

    By the way, really cool discussion.
    Lots of things to think through…



  • Yeah, cool discussion. 🙂
    Thx for your feedback. Some might think it’s an easy task to come up with a solution. But if you dig into it, you will see plenty of unknown and unwanted side-effects that might not be of importance now, but could become of importance later.

    @btmr said in 5-(B) - Security issue of coins:

    If you use many different addresses for privacy reasons or whatever, you simply will have to go the extra mile and vote for each of those addresses. Not convenient, I agree, but I think it’s a necessary inconvenience.

    I totally agree 👍

    If an outgoing transaction is required in order to participate in voting, Bittrex would have to transfer some amount from that address without your consent.

    I don’t think that’s the way exchanges are handling your deposit. They don’t have for each user its own address. Your coins typically end up in a pool of other coins and they just keep your balances for each coin in their own database.
    When Tron bought Steem the exchanges also took an active position during community voting. So there’s no guarantee that exchanges will always keep calm their voting rights.

    This implies that we have to look at an address and check both the amount of staking rewards and balance over a certain amount of time

    Let me give an example for someone who is selling/trading a lot of stuff/coins and who owns 1000 part on address 3A10:
    1st week: he moves his 1000 part to anon and back and they end up on address 3A11
    2nd week: he’s spending 200 part and 800 part end up on his exchange address 3A12
    3rd week: he makes another transaction and his 800 part end up on his address 3A13

    When it comes to voting he would make an outgoing transaction from the final address 3A13 but as averaging amount over the 3 weeks he would only have 800/3 = 266,67 part/week because during week 1 and 2 the balance on this address was still 0.
    To optimize his voting power he would have to make an outgoing transaction from all the four addresses 3A10 … 3A13. Alternatively he could have tried to maintain his balance always on the same address for all the 3 weeks, but that’s for privacy reasons not recommended.

    You know what I mean?



  • @Pancake said in 5-(B) - Security issue of coins:

    I don’t think that’s the way exchanges are handling your deposit. They don’t have for each user its own address. Your coins typically end up in a pool of other coins and they just keep your balances for each coin in their own database.

    Yeah, you are right. Does it matter though, regarding voting participation, if they have one or a thousand addresses? If they vote from one address with a huge balance, they piss of everyone at once.

    When Tron bought Steem the exchanges also took an active position during community voting. So there’s no guarantee that exchanges will always keep calm their voting rights.

    Didn’t know about that. Point taken!

    Let me give an example for someone who is selling/trading a lot of stuff/coins and who owns 1000 part on address 3A10:
    1st week: he moves his 1000 part to anon and back and they end up on address 3A11
    2nd week: he’s spending 200 part and 800 part end up on his exchange address 3A12
    3rd week: he makes another transaction and his 800 part end up on his address 3A13

    When it comes to voting he would make an outgoing transaction from the final address 3A13 but as averaging amount over the 3 weeks he would only have 800/3 = 266,67 part/week because during week 1 and 2 the balance on this address was still 0.
    To optimize his voting power he would have to make an outgoing transaction from all the four addresses 3A10 … 3A13. Alternatively he could have tried to maintain his balance always on the same address for all the 3 weeks, but that’s for privacy reasons not recommended.

    You know what I mean?

    You are saying that anyone shifting balances between multiple addresses would need to vote from/for each of those addresses, in order not to lose voting power. Yes?
    As I wrote above, that’s inconvenient but I think that’s just how it is.

    Maybe we are slowly realizing all the pitfalls of onchain-voting and leave here with “eh, let’s just keep to an offchain p2p-system”…



  • @btmr said in 5-(B) - Security issue of coins:

    Maybe we are slowly realizing all the pitfalls of onchain-voting and leave here with “eh, let’s just keep to an offchain p2p-system”…

    😄 … that what happens when you walk on the edge of technology. That’s why we’re here, to meet a challenge 🤩

    You are saying that anyone shifting balances between multiple addresses would need to vote from/for each of those addresses, in order not to lose voting power.

    If we vote by an outgoing transaction (and I think this would be a valid and good idea), you only have the senders address. I don’t know how you should link this anyhow to its previous addresses. This would make it difficult for those who are actively trading with parts or items, like sellers or liquidity provider. Everyone who makes many transactions.
    As previously described, we could just fix a block-hight (a block number just before the voting period) to make it easier for those to gather up all their coins. So they could transfer all their coins to a single address, waiting until this fixed block-number has past, and then use this particular address for one or more outgoing transactions (where the voting power would relate to the number of coins at the specific time of this fixed block).
    Maybe it’s a bit compareable to the current situation, but since you can also vote with your staking coins you wouldn’t need to move those as well for voting purposes (only the anyhow more “flexible” non-staking public balances).

    During the voting period you might want to vote on several votings. I guess you then would need for each voting a separate outgoing transaction. But I’m not sure about it 🤔

    Let’s see what the foundation comes up with. I think they are also preparing a kind of onchain-voting. Basically I only wanted to collect a kind of “wish-list” based on the communities opinion.

    So let me sum this up as follows. The so far small particl community prefers 😊 :

    1. Minimize the need for “moving” your coins --> e.g. voting by outgoing transaction
    2. Not only the staking coins should be authorized to vote
    3. For not loosing “small investors”, it should be possible for them to delegate their votes e.g. to staking pools
    4. Reducing voting power of big bag holders by a “grading curve”, and make it “uncomfortable” for those to split up their balances due to the need of then multiple outgoing transactions.

    What do you think, can we go with this?
    Does anybody have some other suggestions or missing points to add?



  • My head is spinning so hard trying to keep up with this conversation 😅 you guys are really digging deep 👍


Log in to reply
 

Creative Commons (CC) 2020 - Particl Community | Not affiliated with Particl Foundation | Powered by NodeBB