5-(B) - Security issue of coins



  • @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 👍



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

    What do you think, can we go with this?

    We certainly made progress. Here’s my summary for the case of onchain-voting:

    1. Voting by outgoing transaction as a "spam deterrent"

    2. Voting power to be granted to both staking and non-staking balances
    Arithmetic for calculating and distributing voting power TBD
    Suggestions:
    a) Look at total balance and sum of staking rewards of an address over a period of time. Apply a weighting factor that favors staking balances over non-staking balances and a grading curve that reduces voting power of very large balances*.
    b) Take a snapshot of total balance and sum of staking rewards at a certain moment in time (i.e. block height). Apply a weighting factor that favors staking balances over non-staking balances and a grading curve that reduces voting power of very large balances*.

    3. * Prevent large holders from taking advantage of distributing their coins across multiple addresses and voting through each of them
    Suggestion: enforce rules that declare certain 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,
    TBD

    4. Subscribers to staking pools delegate their power to the pool owner. This way, pools not only compete for best reward scheme but also for best voting policy.

    5. Set defined, time-limited periods for both entering proposals and voting.

    @dadon I hope that makes it easier to get up to speed with this long discussion…
    @Pancake My summary is basically yours with a few details and open items added.



  • I summarized the outcome of this discussions here, and will close this topic.

    In regard to staking voting I still want to refer to following link,
    https://hackernoon.com/voting-determines-the-conversation-how-to-think-about-staking-tokens-3f152185313a
    where also some issues being discribed which later might become of interest as well (e.g. 14-( C))


Log in to reply
 

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