Author Topic: Dividends with Confidential Transactions  (Read 3150 times)

0 Members and 1 Guest are viewing this topic.

Offline cass

  • Hero Member
  • *****
  • Posts: 4311
  • /(┬.┬)\
    • View Profile
@arhag: from what I recall, you are an excellent coder. So why not submit a worker proposal for this in BTS2.0? This seems well worth it!

 +5% @arhag . long time no see .. would love to see you back here :)
█║▌║║█  - - -  The quieter you become, the more you are able to hear  - - -  █║▌║║█

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
@arhag: from what I recall, you are an excellent coder. So why not submit a worker proposal for this in BTS2.0? This seems well worth it!

Offline sittingduck

  • Sr. Member
  • ****
  • Posts: 246
    • View Profile
Much math.   Very cool. 


Sent from my iPhone using Tapatalk

Offline ebit

  • Committee member
  • Hero Member
  • *
  • Posts: 1905
    • View Profile
  • BitShares: ebit
telegram:ebit521
https://weibo.com/ebiter

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
I think we need a nice dividend feature that only requires the issuer to spend a fixed transaction fee rather than transaction fees that scale with the number of recipients of the dividend. While that feature is not strictly necessary to distribute dividends to a snapshot, it is incredibly useful.

However, if the issuer wants to distribute dividends to assets that are blinded using Confidential Transactions, the snapshot and sharedrop method does not work because the issuer cannot know the amounts of the asset each recipient holds. It is in theory possible to distribute dividends to asset holders who blind the asset amounts (that is what I will discuss in this post) but of course it requires new operations. So I strongly encourage a dividend feature that can be used to sharedrop any asset on to any other asset whether blinded or not.


Blinded amounts work through a Pedersen commitment (C) of the asset amount (v, taken to be non-negative) using a random blinding factor (b), e.g. C1 = b1*G + v1*H, where G and H are two different generators that are points on the elliptic curve and H = z*G for some unknown (to anyone) scalar z. A range proof proves that the integer v is within some specified interval (typically we will use the interval [0, 264)) without revealing v or the blinding factor b (the prover needs to know v and b to construct the proof). This is important because we want the fact that the sum of multiple (where multiple means a number less than n/264, where n is the order of the curve, which is practically guaranteed given how large the curve order is) input commitments equals the sum of multiple output commitments to imply that the sum of the values of each of the input commitments equals the sum of the values of each of the output commitments. And that won't hold if there are overflows. So the range proofs on each of the output commitments (the input commitments are assumed to already be in range from either an earlier range proof or because their values were publicly known) guarantees that there won't be any overflows.

Any time someone creates a dividend event, a virtual snapshot is taken on all balances in the database of the asset that the dividend is being sharedropped on. Each asset balance is not just one quantity but rather a current quantity and a (potentially empty) map from dividend events to quantities. (Note when I say quantity here, it can refer to either a plain-text quantity or a Pedersen commitment or even both). The timestamp of the last update to the balance determines how the blockchain should treat any modifications (deposits and withdrawals) to this balance. If the timestamp is not more recent than the most recent dividend event targeting that asset, then the blockchain first needs to add items to the map for each of the dividend events (as the key) that occurred targeting that asset since the timestamp and with the value of each item to the current quantity. Then the blockchain can modify the current quantity as necessary and of course update the timestamp. Each item in the map technically represents a separate asset (it is the ephemeral asset that is used to withdraw the actual dividend asset that rightfully belongs to the user). These ephemeral assets cannot be traded or transferred, they can only be used to withdraw the dividend. After withdrawing the dividend, that item is removed from the map. The item can also be removed from the map anytime after the dividend event referred to by the key has expired (typically such expired items will be checked and removed next time the balance needs to be modified, but perhaps they might also be purged globally at every new maintenance interval).

One thing to be careful with is how to treat assets that are in smart contracts rather than held by accounts. I'm not sure what should be done generally. But at least for assets held in open orders, the quantities in the maps of these orders should be merged in with the correspond map in the account that owns these orders when the orders are cancelled or completely filled. Since the quantities in open orders should be plain-text, it is possible for the blockchain to merge these values through a simple sum without any cooperation needed from the owner (it is actually possible to merge even if the amounts were blinded by just summing the commitments since the owner could calculate the summed blinded factor).

A dividend event records the total aggregate supply (S) of the target asset at the time of the dividend. It also records the total amount of the dividend asset (D) which is "destroyed" as part of the dividend event.  It is very simple for a plain-text withdrawer to withdraw their dividend using the corresponding ephemeral asset (of amount a). The simply use that ephemeral asset (and destroy it in the process) in a dividend withdraw operation to claim an amount (a*D)/S of the dividend.

For a blinded withdrawer to withdraw their dividend the process is a little more complicated. They again use/destroy the ephemeral asset (this time it is a commitment C1) in a dividend withdraw operation to claim some dividend with commitment C2. However, to do this a few things are necessary. First, they must also include a third commitment C3 in their operation. They must include range proofs for both C2 and C3. And finally, the blockchain must verify that S*C2 + C3 == D*C1 (mod n). (Alternatively, the withdrawer can just reveal the amount of C3 and in that case only one expensive range proof is necessary, but I am not sure what kind of privacy leaks revealing the value of C3 may have. So, it is probably better to just accept the cost of the two range proofs for the extra assurance on privacy.)

Now I will prove that the withdrawer can generate C2 and C3 satisfying the above requirements given that they know b1 and v1 where C1 = b1*G + v1*H, and that the above requirements make sense for a dividend distribution:
S*C2 + C3 == D*C1 (mod n)
S*(b2*G + v2*H) + (b3*G + v3*H) == D*(b1*G + v1*H) (mod n)
(S*b2 + b3)*G + (S*v2 + v3) == (D*b1)*G + (D*v1)*H (mod n)
Therefore, b2 == S-1*(D*b1 - b3) (mod n),
and  S*v2 + v3 == D*v1 (mod n).

Given that the values S, D, v1, v2, and v3 are all less than 264 and n is greater than 2128, then if we further assume that v3 is less than S, we can conclude that v2 == (D*v1) / S and v3 == (D*v1) % S, which is the way the withdrawer calculates those values. And even if v3 is not less than S, that only hurts the withdrawer because it reduces the value of v2, which is the quantity of the dividend asset the withdrawer gets to withdraw. Also, the withdrawer can choose any random value for blinding factor b3, and from that can calculate b2 = S-1*(D*b1 - b3) (mod n), where S-1 is in the interval [0, n) and is the inverse of S such that S-1 * S == 1 (mod n). With all the blinding factors and values known, it is possible for the withdrawer to calculate the commitments C2 and C3 and their range proofs.

There will likely be some recipients of the dividend who held the target asset as a blinded amount and who do not bother to go through the withdraw process. Even if they all did, because of rounding errors there would be some amount of the dividend still left unclaimed. If we were not dealing with blinded amounts, it would be possible to known exactly how much was unclaimed by the expiration time and the issuer could take the unclaimed amount back. However, because of the nature of blinded amounts, it is not possible for anyone to know how much of the dividend is left unclaimed. Therefore, we treat distributing the dividend as a two part process where the full amount of the dividend is first destroyed at the time of the dividend distribution and then later some of that destroyed amount is automatically reissued through the withdraw process. However, because of rounding down and some recipients not bothering to withdraw by the expiration time, that new amount will be less than the amount destroyed. But anyone calculating the supply must assume that the full amount of the dividend is still circulating (even though some unknown amount of it is forever inaccessible).

This is a bit troubling when the dividend asset is a BitAsset. It means that it will be impossible to fully unwind the BitAsset supply to zero. But that was already the case if we assumed some users would lose their private keys. When a particular BitAsset becomes obsolete and naturally unwinds to a very small supply, it won't take too much longer for a forced settlement to eventually occur allowing the supply to finally unwind to zero. In that case, there will be some amount of BTS held by the blockchain that will never be claimed because there aren't any remaining accessible BitAssets to claim them. To prevent blockchain bloating, there can be an expiration time (of several years) for users to claim the collateral asset of their settled BitAssets. After that expiration time, the remaining BTS held in the pool can be destroyed along with all the other metadata that was necessary to store in the database to allow people to claim the collateral.

The dividend feature is also useful for any UIA holders who want to transition from allowing their UIAs to be used with Confidential Transactions (which necessarily prevents them from being able to seize the UIAs) to disallowing it (for example because they now want to be able to seize the assets or keep track of the amounts their customers hold). They would first issue a new UIA to eventually replace their old UIA. It would forbid its use in Confidential Transactions but otherwise be identical. The issuer then does a 1-to-1 dividend of the new UIA dropped on the old UIA. Right after that moment, the old UIA becomes worthless (by decree of the issuer anyway) and all of its value goes to the new UIA. It is probably best for the UIA issuer to halt all trading of the asset prior to the dividend. Holders of the old UIA at the moment of the dividend still have some time (likely more than a year) to withdraw the new UIA before the dividend expires. However, to actually withdraw, they are forced to reveal the blinded amounts of their UIA since they cannot use blinded amounts with the new UIA. After the dividend expires, the issuer can then destroy the old UIA (I assume that fully destroying a UIA is a different permission than seizing it, because even when some people use blinded amounts with the UIA it is still technically possible to destroy the UIA even if it is not technically possible to seize it), which frees up any old blockchain metadata that was only supporting the old UIA. Through this process, the public is also able to know the true supply of the UIA rather than just an upper bound.

Another useful way to use the dividend feature is to change the precision of the asset (or conceptually change the unit of value represented by a single satoshi of the UIA). The issuer can create a new UIA that is identical to the old one except it has different precision (either actually and/or conceptually). Using a mechanism similar to that described in the previous paragraph (although no need to disallow blinded values), the issuer can cause an instantaneous transfer of value from the old UIA to the new UIA, but allow users to transition from old to new over a much longer period of time. A procedure like this would be very useful (especially if automated) for a UIA that inflates at a fast rate (and doesn't deflate) as a mechanism of redistributing the value of the asset from some holders to other holders (e.g. a UIA used as a reputation coin in an Augur-like decentralized oracle).
« Last Edit: July 21, 2015, 12:13:14 am by arhag »