maximum confidential amount adjustment #127

wintercooled · 2020-03-24T10:42:52Z

Since increasing the default ct_bits to 52 from 38, the new “maximum confidential amount” is just over 45 million (BTC units).

dgpv · 2020-03-24T11:18:31Z

features/confidential-transactions/index.md

-The implementation only hides a certain number of the digits of the amount of each transaction output, dependent on the range proof's "blinding coverage" at a desired precision level.  Subsequently, there is a "minimum confidential amount" around 0.0001, and a "maximum confidential amount" that is 2<sup>32</sup> times the minimum amount.
-
-Digits smaller than the minimum will be revealed to observers; for example, if the minimum is 0.0001, a transaction output of 123.456789 will look like "?.????89". The tiny amount of information about the value leaked in this way is unlikely to be important, but be aware that this could allow observers to "follow" coins by linking subsequent transactions with identical amounts. All values can be rounded to the minimum to avoid revealing information in this way if preferred.
+The implementation only hides a certain number of the digits of the amount of each transaction output, dependent on the range proof's "blinding coverage" at a desired precision level.  Subsequently, the default "maximum confidential amount" is just over 45 million (45,035,996.27370496). For assets that are pegged to Bitcoin, such as L-BTC on the Liquid network, it is impossible to exceed 2^52 satoshis. For other Issued Assets it may be possible to exceed the maximum confidential amount by repeatedly reissuing the asset and then spending an amount greater than the limit in a single transaction, and so the limitation should be noted.


Is it actually limited by 52 bits, or this is only a default setting for Elements client ?
ElementsProject/elements#834 allows to set ct_bits to any value, and only secp256k1-zkp library checks will be the limiting factor, AFAIU.

The check in secp256k1-zkp lib is for 64 bits, not 52 bits:
https://github.com/ElementsProject/secp256k1-zkp/blob/cad7cc8f34d17166da2dabae20188ea6e747ac69/src/modules/rangeproof/rangeproof_impl.h#L217

Yeah Dmitri is correct here. I think the wording is a bit confusing. I think it would be better to just say that "the default blinding precision is 52-bits, which will cover any value up to 2^52 satoshis (for L-BTC this is 45 million)". It's not a maximum, but it's just the default (that both Elements Core and Green have, which I think is the vast majority of our users).

stevenroose · 2020-03-24T18:06:13Z

features/confidential-transactions/index.md


 A transaction output larger than the maximum will reveal the order of magnitude of the amount to observers, and will also reveal additional digits at the bottom of the amount.

-For example, if the maximum is 500k, then all outputs under that amount will look the same, but an output between 500k and 5M will be visible as such to observers (but not the exact amount within that range), and will also reveal one additional digit of the low end of the amount. Revealing the range in this way could be a very significant privacy leak; splitting such extremely large transactions to keep them under the maximum confidential amount is strongly recommended.
+For example, if the maximum is 45 million, then all outputs under that amount will look the same, but an output between 45 million and 450 million will be visible as such to observers (but not the exact amount within that range), and will also reveal one additional digit of the low end of the amount. Revealing the range in this way could be a very significant privacy leak; splitting such extremely large transactions to keep them under the maximum confidential amount is strongly recommended.


Again perhaps instead of talking about a "maximum" you could talk about "if the user uses a blinding precision of 52 bits, ...." to indicate that it's an option and suggest that 52 is the default.

Updated for review @stevenroose and @dgpv - thanks for feedback

dgpv · 2020-03-25T10:38:57Z

features/confidential-transactions/index.md

-The implementation only hides a certain number of the digits of the amount of each transaction output, dependent on the range proof's "blinding coverage" at a desired precision level.  Subsequently, there is a "minimum confidential amount" around 0.0001, and a "maximum confidential amount" that is 2<sup>32</sup> times the minimum amount.
-
-Digits smaller than the minimum will be revealed to observers; for example, if the minimum is 0.0001, a transaction output of 123.456789 will look like "?.????89". The tiny amount of information about the value leaked in this way is unlikely to be important, but be aware that this could allow observers to "follow" coins by linking subsequent transactions with identical amounts. All values can be rounded to the minimum to avoid revealing information in this way if preferred.
+The implementation only hides a certain number of the digits of the amount of each transaction output, dependent on the range proof's "blinding coverage" at a desired precision level. The default blinding precision is 52-bits, which will cover any value up to 2^52 satoshi. The default equates to a maximum amount of just over 45 million. For assets that are pegged to Bitcoin, such as L-BTC on the Liquid network, this provides cover for all possible pegged asset transactions. It should be noted that for Issued Assets it is possible to exceed the default maximum confidential amount by repeatedly reissuing the asset and then spending an amount greater than the limit in a single transaction.


nit: why there's a dash in "52-bits", shouldn't it be just "52 bits" ?

noted - fixed in latest commit.

dgpv · 2020-03-25T13:03:35Z

features/confidential-transactions/index.md

-The implementation only hides a certain number of the digits of the amount of each transaction output, dependent on the range proof's "blinding coverage" at a desired precision level.  Subsequently, there is a "minimum confidential amount" around 0.0001, and a "maximum confidential amount" that is 2<sup>32</sup> times the minimum amount.
-
-Digits smaller than the minimum will be revealed to observers; for example, if the minimum is 0.0001, a transaction output of 123.456789 will look like "?.????89". The tiny amount of information about the value leaked in this way is unlikely to be important, but be aware that this could allow observers to "follow" coins by linking subsequent transactions with identical amounts. All values can be rounded to the minimum to avoid revealing information in this way if preferred.
+The implementation only hides a certain number of the digits of the amount of each transaction output, dependent on the range proof's "blinding coverage" at a desired precision level. The default blinding precision is 52 bits, which will cover any value up to 2^52 satoshi. The default equates to a maximum amount of just over 45 million. For assets that are pegged to Bitcoin, such as L-BTC on the Liquid network, this provides cover for all possible pegged asset transactions. It should be noted that for Issued Assets it is possible to exceed the default maximum confidential amount by repeatedly reissuing the asset and then spending an amount greater than the limit in a single transaction.


You cannot have output with nValue > MAX_MONEY, and MAX_MONEY in Elements is the same as in Bitcoin Core, so it seems that the last sentence does not apply anymore for ct_bits=52

Relevant code block:
https://github.com/ElementsProject/elements/blob/ac5a435247b10b74fbaab9817ce7d199675b3d29/src/consensus/tx_verify.cpp#L197-L212

You cannot have an unconfidential output with that amount. Confidential likely works(wallet might get confused?)

Or rather it applies for values of CT_BITS < 51

Right, confidential amounts cannot be checked for MAX_MONEY.

By the way, what happens when I issue asset with confidential amount 2^64-1 and then reissue it ? I can have total asset supply more than 2^64 ? (cannot do it via RPC, but it seems that there's nothing that stops from doing this via manually crafting a transaction)

You wouldn't be able to create a rangeproof for a single output of more than 64 bits of hiding, IIUC

Right, first 64 bits in the (single) output of an issuance, and another 64 bits in the (single) output of a reissuance (and another 64 bits in the second reissuance...) -- total asset supply in first two outputs would be 2*(2^64-1)

(wallet might get confused?)

before that, UnblindConfidentialPair will fail: https://github.com/ElementsProject/elements/blob/3c029f42bdb763c6b29512fdbdaef6c135708f2e/src/blind.cpp#L93

So the wallet will store that UTXO with value = -1 and ignore it

instagibbs · 2020-03-25T20:13:43Z

That's good to know and actually an ok failure considering the alternatives.

…

On Wed, Mar 25, 2020, 3:57 PM Dmitry Petukhov ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In features/confidential-transactions/index.md <#127 (comment)> : > @@ -90,13 +90,11 @@ elements-cli sendrawtransaction $TX The implementation of Confidential Transactions as it appears in Elements has some important limitations to be aware of. -The implementation only hides a certain number of the digits of the amount of each transaction output, dependent on the range proof's "blinding coverage" at a desired precision level. Subsequently, there is a "minimum confidential amount" around 0.0001, and a "maximum confidential amount" that is 2<sup>32</sup> times the minimum amount. - -Digits smaller than the minimum will be revealed to observers; for example, if the minimum is 0.0001, a transaction output of 123.456789 will look like "?.????89". The tiny amount of information about the value leaked in this way is unlikely to be important, but be aware that this could allow observers to "follow" coins by linking subsequent transactions with identical amounts. All values can be rounded to the minimum to avoid revealing information in this way if preferred. +The implementation only hides a certain number of the digits of the amount of each transaction output, dependent on the range proof's "blinding coverage" at a desired precision level. The default blinding precision is 52 bits, which will cover any value up to 2^52 satoshi. The default equates to a maximum amount of just over 45 million. For assets that are pegged to Bitcoin, such as L-BTC on the Liquid network, this provides cover for all possible pegged asset transactions. It should be noted that for Issued Assets it is possible to exceed the default maximum confidential amount by repeatedly reissuing the asset and then spending an amount greater than the limit in a single transaction. (wallet might get confused?) before that, UnblindConfidentialPair will fail: https://github.com/ElementsProject/elements/blob/3c029f42bdb763c6b29512fdbdaef6c135708f2e/src/blind.cpp#L93 So the wallet will store that UTXO with value = -1 and ignore it — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#127 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMAFU6PK7MGAW3KCSCGW53RJJO2BANCNFSM4LSRNBRA> .

stevenroose

Apart from my 2 comments, looks good.

stevenroose · 2020-04-07T12:58:39Z

features/confidential-transactions/index.md


-The implementation only hides a certain number of the digits of the amount of each transaction output, dependent on the range proof's "blinding coverage" at a desired precision level.  Subsequently, there is a "minimum confidential amount" around 0.0001, and a "maximum confidential amount" that is 2<sup>32</sup> times the minimum amount.
+The implementation only hides a certain number of the digits of the amount of each transaction output, dependent on the range proof's "blinding coverage" at a desired precision level. The default blinding precision is currently 52 bits, which will cover any value up to 2^52 satoshi, which equates to a maximum amount of just over 45 million. As the maximum amount that can be transacted is inherited from Bitcoin, and set at 21 million, this currently provides cover for all asset transactions.


any value up to 2^52 satoshi, which equates to a maximum amount of just over 45 million

45 million BTC*

Lateron also 21 million BTC*.

The amount is not necessary in BTC, it may be some other asset. Maybe "X million coins" ?

...or X million BTC equivalent units.

Bit wordy though.

dgpv reviewed Mar 24, 2020

View reviewed changes

stevenroose reviewed Mar 24, 2020

View reviewed changes

dgpv reviewed Mar 25, 2020

View reviewed changes

dgpv mentioned this pull request Mar 25, 2020

Switch default bits of hiding to 52 ElementsProject/elements#834

Merged

wintercooled added 4 commits April 7, 2020 13:00

maximum confidential amount adjustment

770fc7b

refer to 52 bits as default

d3de4d4

remove dash

f28120d

Notes on default max tx amount

7630fae

stevenroose requested changes Apr 7, 2020

View reviewed changes

unit clarification

5d1f823

wintercooled merged commit bdd973a into ElementsProject:master Apr 9, 2020

wintercooled mentioned this pull request Apr 9, 2020

features/confidential-transactions shows values for CT_BITS=32, but now CT_BITS is 52 #126

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

maximum confidential amount adjustment #127

maximum confidential amount adjustment #127

wintercooled commented Mar 24, 2020

dgpv Mar 24, 2020

stevenroose Mar 24, 2020

stevenroose Mar 24, 2020

wintercooled Mar 25, 2020

dgpv Mar 25, 2020

wintercooled Mar 25, 2020

dgpv Mar 25, 2020 •

edited

Loading

instagibbs Mar 25, 2020

dgpv Mar 25, 2020

dgpv Mar 25, 2020 •

edited

Loading

instagibbs Mar 25, 2020

dgpv Mar 25, 2020 •

edited

Loading

dgpv Mar 25, 2020 •

edited

Loading

instagibbs commented Mar 25, 2020 via email

stevenroose left a comment

stevenroose Apr 7, 2020

stevenroose Apr 7, 2020

dgpv Apr 7, 2020

wintercooled Apr 7, 2020


		The implementation only hides a certain number of the digits of the amount of each transaction output, dependent on the range proof's "blinding coverage" at a desired precision level. Subsequently, there is a "minimum confidential amount" around 0.0001, and a "maximum confidential amount" that is 2<sup>32</sup> times the minimum amount.
		The implementation only hides a certain number of the digits of the amount of each transaction output, dependent on the range proof's "blinding coverage" at a desired precision level. The default blinding precision is currently 52 bits, which will cover any value up to 2^52 satoshi, which equates to a maximum amount of just over 45 million. As the maximum amount that can be transacted is inherited from Bitcoin, and set at 21 million, this currently provides cover for all asset transactions.

maximum confidential amount adjustment #127

maximum confidential amount adjustment #127

Conversation

wintercooled commented Mar 24, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dgpv Mar 25, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dgpv Mar 25, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dgpv Mar 25, 2020 • edited Loading

Choose a reason for hiding this comment

dgpv Mar 25, 2020 • edited Loading

Choose a reason for hiding this comment

instagibbs commented Mar 25, 2020 via email

stevenroose left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dgpv Mar 25, 2020 •

edited

Loading

dgpv Mar 25, 2020 •

edited

Loading

dgpv Mar 25, 2020 •

edited

Loading

dgpv Mar 25, 2020 •

edited

Loading