19

Most of the information below is taken from this post on the GetMonero website. To understand bulletproofs, you need to first understand what a range proof is. According to the post: A range proof allows anyone to verify that a commitment represents an amount within a specified range, without revealing anything else about its value. Monero uses the ...


13

Suppose the sender wants to create a Pedersen Commitment to the amount of 23 XMR for a new output pubkey in a transaction. Without range proof, the sender simply creates the commitment as: C = a G + 23 H where a is a random scalar. With range proof, there's an assumption in the protocol that any committed amount falls within a certain range; let's say ...


13

Full nodes cannot prune the range proofs entirely in a trustless manner. SPV nodes and those relying on checkpoints could benefit in the manner described by Monero Research Labs below: While the range proofs are large, using a transaction hashing scheme that signs the transaction "prefix" (both input indices and outputs) and stores the range proof, ...


10

This is a bit speculative, as I do not know exactly what is planned. 1024+ bytes is quite a reduction, so my guess is that the range will be reduced. Currently the spender must prove the output is in the range [0, 2^64), and if the upper limit were reduced it would reduce the size of the signature. This would not alter security, but would decrease the ...


9

They are currently 6304 bytes (per output). This will drop in the future by at least 1024 bytes. Beyond that will change (or not) with design decisions yet to be made.


9

The signatures, whether pre or post RingCT, are not needed for a node's own use after they are verified. However, pruning them means the node is unable to supply the full chain to peers, since those peers would need the signature so they can check them too. Allowing pruning in that way means the set of full "archival" nodes would be smaller than it otherwise ...


7

There were two main reasons outputs were called dust: small outputs (typically well below 0.01, which is the fee per kB) "complex looking" amounts, such 0.000013852456 The problem with the first type is that they might not "pay for themselves" in fees. Since fees in Monero are 0.01 per kB, if you use only small outputs, you may end up with a transaction ...


5

A good description of this is found in Greg Maxwell's paper on CT: (1 + 1) - (-5 + 7) == 0 This would be interpreted as "someone spends two bitcoins, gets a '-5' bitcoin out that they discard out, and a 7 bitcoin output". If we substitute your example values: (10 + 11) - (31 + -10) == 0 The commitment is to zero and the -10 output is simply discarded (...


5

Bulletproofs are used to prove that the amounts in confidential transactions are in range, so you can't do underhanded things like creating negative amounts. They replace Borromean range proofs. They are smaller in size, and faster to verify, though slower to generate. As used in Monero, they are unrelated to ring signatures, but are part of RingCT, since ...


5

Technically, I think it's possible to use the range proof scheme (whether using Borromean or Bulletproofs) to prove that the amount committed by a given Pedersen Commitment falls within a certain range. A Pedersen Commitment C committing to an amount a using a mask (aka. blinding factor) x is represented as C = x*G + a*H where G and H are protocol-defined ...


3

Can someone please explain the technical method by which this can be completed successfully? The range proof requires generating a lot of random values in the process. Nothing would change security-wise if that data was not entirely random and carried some encrypted payload instead. What are the advantages of using this method over the current txextra ...


3

It could be argued that there's no need to re-adjust M_0 again as just reducing typical TX size would give us more margin and would further reduce the effect of TX size / block size ratio. However, do-not-relay fee could be adjusted at any time to keep the price/fiat at some reasonable level and deter irrational network use. The more TX-es can fit in a ...


3

tl;dr: OutProofV1 strings prove you had access to the wallet that constructed a particular transaction. SpendProofV1 strings are used when some wallet information has been lost (because txkeys are lost forever if you don't store them), and instead prove you had full knowledge of the private keys of the inputs being spent in a transaction. Strings ...


3

First of all, each Pedersen Commitment hides the committed amount by adding a random "blinding factor", so two commitments committing to the same amount will look completely differently. Second, the range proof generation algorithm internally uses a lot of random numbers, so even for the same Pedersen Commitment, two or more range proofs will look ...


2

It is partially possible and will probably be implemented in the future. An interesting post was created about this and a member of the Monero Research Lab stated the following 8 hours ago: [...] Currently, the only way to prove your balance to an auditor is to give them your view secret key along with the set of signed key images (i.e. ingredients ...


2

The Monero wallets (official or any others that I'm aware of), do not offer any functionality to perform generic range proofs. For a generic range proof, you could use code as in user679128's answer. If you are a competent Java developer, there is also a Java library created by one of the Bulletproof authors, which could be used to help implement what you ...


2

For security reasons, input points should be multiples of 8. While there is no known exploit if they're not in this case, having them be multiples of 8 means we can rule those out in the first place. The obvious way to ensure this is to check whether input points are multiples of 8 in the verification code. However, this is slow. Multiplying a point by 8 ...


2

latex MRL's paper is confusing, it's better to read the source code. There is a new output we want to make a "range proof". $C=aG+10H$ $10$ is the amount, $a$ is the secret key. G and H are different base point. We split it in four, we get: $C_0=a_0G+0 \times 1H$ $C_1=a_1G+1 \times 2H$ $C_2=a_2G+0 \times 4H$ $C_3=a_3G+1 \times 8H$ because $2+8=10$. ...


1

1st (1 Monero) + 3rd (100 Monero) = 4th_Mine (90 Monero) + range proof balancing (11 Monero) 2nd (1 Monero) + 3rd (100 Monero) = 5th_Mine (90 Monero) + range proof balancing (11 Monero) Let's call these TX1 and TX2 and lay them out a little more accurately. The outputs either being spent or created are denoted by oN. Each real spend output appears in ...


1

T1 is a curve point. It is multiplied by 8 to ensure it is on the main subgroup of the Ed25519 curve.


1

I'll describe conceptually how they work in Monero, since this is the Monero stackexchange. I'd assume they would work similarly when implemented elsewhere. Output amounts are encrypted by the sender using the transaction shared secret, and bundled with the transaction. The transaction shared secret is the result of a Diffie Hellman exchange between the ...


1

Range proofs and and commitments are both kept in the transaction. Version 2 transactions (the ringct ones) now calculate transaction id a bit differently from v1 transactions, by hashing a set of hashes of several parts of the transaction, to allow future pruning of the range proofs. In that hypothetical future, range proofs will thus not be part of the (...


Only top voted, non community-wiki answers of a minimum length are eligible