Did you stop copy paste your straw?
Thank you for providing us with a companion quote to go along with such gems as "Is it true?".
DID YOU STOP COPY PASTE YOUR STRAW? DID YOU?!
Please comment the post.
I am littering it with comments as we speak.
Please compare development of monero with the development of the fathers of the code that your coin uses, ups, sorry, this project was stolen from T_F_T.
steal, verb
1. to take (the property of another or others) without permission or right, especially secretly or by force:
2. to appropriate (ideas, credit, words, etc.) without right or acknowledgment.
This cannot apply to Monero. The license covering the code pre-fork was the MIT license:
https://github.com/bitmonero-project/bitmonero/blob/master/src/cryptonote_config.h#L2Per
the text of the MIT license:
"
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"),
to deal in the Software without restriction, including without limitation
the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software"
So we had permission and right. As for acknowledgement, we have included, and continue to include, a CryptoNote copyright notice on all files that originated from before the fork:
https://github.com/monero-project/bitmonero/blob/master/src/cryptonote_config.h#L29Yes, thats when you scammers started. You Trolleros Devs couldn't even create a genesis block, so you stole the project from T_F_T.
We forked the repo, and retained the social contract implicit in Monero's launch by not relaunching it, thus ensuring that even thankful_for_today was rewarded for his work (ie. as an early miner). If we had relaunched it then it would have been difficult to do so fairly, someone on either side would feel mistreated.
Look what another dev think of your work, 6 months ago, and Monero did not change a thing since then.
Looking at it objectively is always better than quoting the opinion of "another dev", especially when that dev is likely involved in the Bytecoin scam.
You are not just insulting me, you are insulting many others, and your claim is provably untrue. Don't make a statement countering this, provide tangible evidence of your claim.
As for me - monero is a biggest bubble, because there is only speculation about it
Of course there's speculation. But there is also actual use.
blockchain is unusable with its size
How do you suppose you'll have a usable cryptocurrency that is actually used, and yet not have an ever-growing blockchain? What a silly comment, it really shows the desperation of this trolling.
IMO almost everything about monero seems terrible - unusable blockchain size (On average PC, it just can`t be a network node)
Runs just fine on a Raspberry Pi 1 with 256mb RAM, so I guess he must be talking about running it on a 486 DX2 66.
block intervals
Chosen by...thankful_for_today! And here I thought you were hailing him as an incredible human being?
tx generation size
Is
duck dark digital dontcareNote really trying to claim that their transactions are significantly smaller?
fee size
0.001 XMR per kilobyte (most transactions are 1kb-2kb), so that's about $0.0000056 per transaction. Gosh. So expensive.
no GUI after almost 1 year since start
Wrong. There are several GUIs:
https://getmonero.org/getting-started/choosetotally wrong way of development
As opposed to dNote, which has the "totally right" way of development, no? If that's the case, then why have they attracted NO other contributors?
https://github.com/xdn-project/digitalnote/graphs/contributors vs.
https://github.com/monero-project/bitmonero/graphs/contributorslooks like just no understanding of CN technology.
Looks like I've got to rehash some of our research bulletins. Let's do this one:
MRL-0003: Monero is Not That Mysterious1 Introduction
Recently, there have been some vague fears about the CryptoNote source code and protocol floating around the internet based on the fact that it is a more complicated protocol than, for instance, Bitcoin. The purpose of this note is to try and clear up some misconceptions, and hopefully remove some of the mystery surrounding Monero Ring Signatures. I will start by comparing the mathematics involved in CryptoNote ring signatures (as described in [CN]) to the mathematics in [FS], on which CryptoNote is based. After this, I will compare the mathematics of the ring signature to what is actually in the CryptoNote codebase.
2 CryptoNote Origins
As noted in ([CN], 4.1) by Saberhagen, group ring signatures have a history starting as early as 1991 [CH], and various ring signature schemes have been studied by a number of researchers throughout the past two decades. As claimed in ([CN] 4.1), the main ring signature used in CryptoNote is based on [FS], with some changes to accomodate blockchain technology.
2.1 Traceable Ring Signatures
In [FS], Fujisaki and Suzuki introduce a scheme for a ring signature designed to “leak secrets anonymously, without the risk of identity escrow.” This lack of a need for identity escrow allows users of the ring signature to hide themselves in a group with an inherently higher level of distrust compared to schemes relying on a group manager.
In ring-signature schemes relying on a group manager, such as the original ring signatures described in [CH], a designated trusted person guards the secrets of the group participants. While anonymous, such schemes rely, of course, on the manager not being compromised. The result of having a group-manager, in terms of currencies, is essentially the same as having a trusted organization or node to mix your coins.
In contrast, the traceable ring signature scheme given in [FS] has no group manager. According to [FS], there are four formal security requirements to their traceable ring signature scheme:
• Public Traceability -Anyone who creates two signatures for di.erent mes.sages with respect to the same tag can be traced. (In CryptoNote, if the user opts not to use a one-time key for each transaction, then they will be traceable, however if they desire anonymity, then they will use the one-time key. Thus as stated on page 5 of [CN], the traceability property is weakened in CryptoNote.)
• Tag-Linkability -Every two signatures generated by the same signer with respect to the same tag are linked. (This aspect in CryptoNote refers to each transaction having a key image which prevents double spending.)
• Anonymity -As long as a signer does not sign on two di.erent messages with respect to the same tag, the identity of the signer is indistinguishable from any of the possible ring members. In addition, any two signatures gen.erated with respect to two distinct tags are always unlinkable. (In terms of CryptoNote, if the signer attempts to use the same key-image more than once, then they can be identified out of the group. The unlinkability aspect is retained and is a key part of CryptoNote.)
• Exculpability -An honest ring member cannot be accused of signing twice with respect to the same tag. In other words, it should be infeasible to counterfeit a tag corresponding to another person’s secret key. (In terms of CryptoNote, this says that key images cannot be faked.)
In addition, [FS] provide a ring signature protocol on page 10 of their paper, which is equivalent to the CryptoNote ring signature algorithm, as described on page 9-10 of [CN]. It is worthwhile to note that [FS] is a publicly peer-reviewed publication appearing in Lecture Notes in Computer Science, as opposed to typical crypto.currency protocol descriptions, where it is unclear whether or not they have been reviewed or not.
2.2 Traceability vs CryptoNote
In the original traceable ring signature algorithm described in [FS], it is possible to use the tag corresponding to a signature multiple times. However, multiple uses of the tag allow the user to be traced; in other words, the signer’s index can be determined out of the group of users signing. It is worthwhile to note that, due to the exculpability feature of the protocol ([FS] 5.6, [CN], A2), keys cannot be stolen this way, unless an attacker is able to solve the Elliptic Curve Discrete Logarithm Problem (ECDLP) upon which a large portion of modern cryptography is based ([Si] XI.4).
The process to trace a tag used more than once is described on ([FS], page 10). In the CryptoNote protocol, however, key images (tags) used more than once are rejected by the blockchain as double-spends, and hence traceability is not an aspect of CryptoNote.
2.3 Tag-Linkability vs CryptoNote
In essence, the tag-linkability aspect of the traceable ring signature protocol is what prevents CryptoNote transactions from being double-spends. The relevant protocols are referred to as “Trace” in ([FS], 5) and “LNK” in the CryptoNote paper. Essentially all that is required is to be able to keep track of the key images which have been used before, and to verify that a key image is not used again.
If one key-image is detected on the blockchain before another key-image, then the second key image is detected as a double-spend transaction. As key-images cannot be forged, being exculpable, the double-spender must in fact be the same person, and not another person trying to steal a wallet.
3 One-Time Ring Signatures (mathematics)
The security of the ring signature scheme as described in ([FS] 10, [CN] 10) and implemented in the CryptoNote source relies on the known security properties of Curve25519. Note that this is the same curve used in OpenSSH 6.5, Tor, Apple iOS, and many other[1] security systems.
3.1 Twisted Edwards Curves
The basic security in the CryptoNote Ring Signature algorithm is guaranteed by the ECDLP ([Si], XI.4) on the Twisted Edwards curve ed25519. The security properties of curve ed25519 are described in [Bern], by noted cryptographer Daniel Bernstein, andin([BCPM])byateamfromMicrosoftResearch.Bernsteinnotesabouted25519 the “every known attack is more expensive than performing a brute-force search on a typical 128-bit secret-key cipher.”
The curve ed25519 is a singular curve of genus 1 with a group law, and described
2 .121665 22
by .x+ y2 =1+xy. This curve is considered over the finite field Fq,
121666q =2255 . 19. For those readers unfamiliar with algebraic geometry, an algebraic curve is considered as a one dimensional sort of space, consisting of all points (x, y) satisfying the above equation. All points are also considered modulo q. By virtue of its genus, ed25519 has a “group structure” which, for the purpose of this discussion, means if P =(x1,y1) is a point on the curve, and Q =(x2,y2) is another point on the curve, then these points can be added (or subtracted) and the sum (or di.erence), P + Q (or P . Q) will also be on the curve. The addition is not the naive adding of x1 + x2 and y1 + y2, but instead points are added using the rule
x1y2 + y1x2 y1y2 + x1x2
P + Q = ,
1+ dx1x2y1y2 1 . dx1x2y1y2
.121665
[1]http://ianix.com/pub/curve25519-deployment.html
where d =([BBJLP] 6, [BCPM]). The mathematics of curves of genus one are explained in great detail in [Si] for the interested reader.
Based on the above, we can compute P +P for any such point. In order to shorten notation, we rely on our algebraic intuition and denote 2P = P + P . If n . Z, then nP denotes the repeated sum
P + P + ··· + P
P+_ P
n times
using the above nonlinear addition law. As an example of how this di.ers from ordinary addition, consider the following system of equations:
aP + bQ = X
aP ' + bQ' = Y
where a, b, c, d are integers and P, Q, X are points. If this were a standard system of linear equations then one could use linear algebraic techniques to easily solve for a and b, assuming that P, Q, X, Y, P ', and Q ' are known. However, even if a, b are very small the above system is extremely di.cult to solve using the ed25519 addition law. For example, if a =1 and b =1, we have
xP yQ + yP xQ yP yQ + xP xQ
, =(xX ,yX )
1+ dxP xQyP yQ 1 . dxP xQyP yQ
xP 1 yQ1 + yP 1 xQ1 yP 1 yQ1 + xP 1 xQ1
, =(xY ,yY )
1+ dxP 1 xQ1 yP1 yQ1 1 . dxP 1 xQ1 yP 1 yQ1
So in reality, this is a system of 4 nonlinear equations. To convince yourself that it is in fact di.cult to figure out a and b, try writing the above systems assuming a =2, b =1. It should become clear that the problem is extremely di.cult when a, b are chosen to be very large. As of yet, there are no known methods available to e.ciently solve this system for large values of a and b.
Consider the following problem. Suppose your friend has a random integer q, and computes qP using the above form of addition. Your friend then tells you the x and y coordinates qP =(x, y), but not what q itself is. Without asking, how do you find out what q is? A naive approach might be to start with P and keep adding P + P + P... until you reach qP (which you will know because you will end up at (x, y)). But if q is very large then this naive approach might take billions of years using modern supercomputers. Based on what mathematicians currently know about the problem and the number of possible q, none of the currently known attacking techniques can, as a general rule, do better in any practical sense than brute force.
In CryptoNote, your secret key is essentially just a very, very large number x (for other considerations, see section 4.3.3, we choose x to be a multiple of
. There is a special point G on the curve ed25519 called “the base point” of the curve which is used as the starting point to get xG. Your public key is just xG, and you are protected by the above problem from someone using known information to determine the private key.
3.2 Relation to Diffie Helman
Included in a ring signature are the following equations involving your secret key x:
P = xG
I = xHp (P )
rs = qs . csx.
Here s is a number giving the index in the group signature to your public key, and Hp (P ) is a hash function which deterministically takes the point P to another point
''
P = x ' G, where x is another very large uniformly chosen number. The value qs is chosen uniformly at random, and cs is computed using another equation involving random values. The particular hash function used in CryptoNote is Keccak1600, used in other applications such as SHA-3; it is currently considered to be secure ([FIPS]). The CryptoNote use of a single hash function is consistent with the standard procedure of consolidating distinct random oracles (in proofs of security in [FS], for example) into a single strong hash function.
The above equations can be written as follows:
P = xG
' ' G '
P = xx
rs = qs . csx
Solving the top two equations is equivalent to the ECDH (as outlined in a previ.ous note ([SN])) and is the same practical di.culty as the ECDLP. Although the equations appear linear, they are in fact highly non-linear, as they use the addition described in 3.1 and above. The third equation (with unknowns qs and x), has the di.culty of finding a random number (either qs or x) in Fq, a very large finite field; this is not feasible. Note that as the third equation has two unknowns, combining it with the previous two equations does not help; an attacker needs to determine at least one of the random numbers qs or x.
3.3 Time Cost to Guess q or x
Since q and x are assumed to be random very large numbers in Fq , with q = 2255 . 19 (generated as 32-byte integers), this is equivalent to a 128-bit security level ([BCPM]), which is known to take billions of years to compute with current supercomputers.
3.4 Review of Proofs in Appendix
In the CryptoNote appendix, there are four proofs of the four basic properties required for security of the one-time ring-signature scheme:
• Linkability (protection against double-spending)
• Exculpability (protection of your secret key)
• Unforgeability (protection against forged ring signatures)
• Anonymity (ability to hide a transaction within other transactions) These theorems are essentially identical to those in [FS] and show that the ring signature protocol satisfies the above traits. The first theorem shows that only the secret keys corresponding to the public keys included in a group can produce a signature for that group. This relies on the ECDLP for the solution of two simulta.neous (non-linear) elliptic curve equations, which, as explained in 3.2, is practically unsolvable. The second theorem uses the same reasoning, but shows that in order to create a fake signature that passes verification, one would need to be able to solve the ECDLP. The third and fourth theorems are taken directly from [FS].
4 One-Time Ring Signatures (Application)
To understand how CryptoNote is implementing the One-Time Ring signatures, I built a model in Python of Crypto-ops.cpp and Crypto.cpp from the Monero source code using naive Twisted Edwards Curve operations (taken from code by Bernstein), rather than the apparently reasonably optimized operations existing in the CryptoNote code. Functions are explained in the code comments below. Using themodelwillproduceaworkingringsignaturethatdi.ersslightlyfromtheMonero ring signatures only because of hashing and packing di.erences between the used libraries. The full code is hosted at the following address:
https://github.com/monero-project/mininero Note that most of the important helper functions in crypto-ops.cpp in the CryptoNote source are pulled from the reference implementation of Curve25519. This reference implentation was coded by Matthew Dempsky (Mochi Media, now Google)[2].
In addition, after comparing the python code to the paper, and in turn comparing the python code to the actual Monero source, it is fairly easy to see that functions like generate_ring_sig are all doing what they are supposed to based on the pro.tocol describedinthewhitepaper. For example,here is the ring signature generation algorithm used in the CryptoNote source:
Algorithm 1 Ring Signatures
i . 0
while i < numkeys do
if i = s then
k . random Fq element
Li . k · G
Ri . k ·Hp(Pi)
else
k1 . random Fq element
k2 . random Fq element
Li . k1Pi + k2G
Ri . k1I + k2Hp(Pi)
ci . k1
ri . k2
end if
i . i +1
end while
h .Hs(prefix + L.is + R.is))
p
cs . h . i ci
=s
rs . k . xcs
return (I, {ci}, {ri})
Comparing this with [CN] shows that it agrees with the whitepaper. Similarly, here is the algorithm used in the CryptoNote source to verify ring signatures:
Algorithm 2 VER
i =0
while i < numkeys do L.. ciPi + riG
i R.. riHp(Pi)+ ciI
i
i . i +1
end while
h .Hs(prefix + L.is + R.is))
p
h . h .
i
=s ci return (h == 0(mod q)) == 0
4.1 Important Crypto-ops Functions
Descriptions of important functions in Crypto-ops.cpp. Even more references and information is given in the comments in the MiniNero.py code linked above.
[2]http://nacl.cr.yp.to/
4.1.1 ge_frombytes_vartime
Takes as input some data and converts to a point on ed25519. For a reference of (q.5)/837 the equation used, . = uvuv, see ([BBJLP], section 5).
4.1.2 ge_fromfe_frombytesvartime
Similar to the above, but compressed in another form.
4.1.3 ge_double_scalarmult_base_vartime
Takes as inputs two integers a and b and a point A on ed25519 and returns the point aA + bG, where G is the ed25519 base point. Used for the ring signatures when computing, for example, Li with i = s as in ([CN], 4.4)
4.1.4 ge_double_scalarmult_vartime
Takes as inputs two integers a and b and two points A and B on ed25519 and outputs aA + bB. Used, for example, when computing the Ri in the ring signatures with i = s ([CN], 4.4)
4.1.5 ge_scalarmult
Given a point A on ed25519 and an integer a, this computes the point aA. Used for example when computing Li and Ri when i = s.
4.1.6 ge_scalarmult_base
Takes as input an integer a and computes aG, where G is the ed25519 base point.
4.1.7 ge_p1p1_to_p2
There are different representations of curve points for ed25519, this converts between them. See MiniNero for more reference.
4.1.8 ge_p2_dbl
This takes a point in the “p2” representation and doubles it.
4.1.9 ge_p3_to_p2
Takes a point in the “p3” representation on ed25519 and turns it into a point in the “p2” representation.
4.1.10 ge_mul8
This takes a point A on ed25519 and returns 8A.
4.1.11 sc_reduce
Takes a 64-byte integer and outputs the lowest 32 bytes modulo the prime q. This is not a CryptoNote-specific function, but comes from the standard ed25519 library.
4.1.12 sc_reduce32
Takes a 32-byte integer and outputs the integer modulo q. Same code as above, except skipping the 64.32 byte step.
4.1.13 sc_mulsub
Takes three integers a, b, c in Fq and returns c . ab modulo q.
4.2 Important Hashing Functions
4.2.1 cn_fast_hash
Takes data and returns the Keccak1600 hash of the data.
4.3 Crypto.cpp Functions
4.3.1 random_scalar
Generates a 64-byte integer and then reduces it to a 32 byte integer modulo q for 128-bit security as described in section 3.3.
4.3.2 hash_to_scalar
Inputs data (for example, a point P on ed25519) and outputs Hs (P ), which is the Keccak1600 hash of the data. The function then converts the hashed data to a 32-byte integer modulo q.
4.3.3 generate_keys
Returns a secret key and public key pair, using random_scalar (asdescribed above) to get the secret key. Note that, as described in [Bern], the key set for ed25519 actually is only multiples of 8 in Fq, and hence ge_scalarmult_base includes a ge_mul8 to ensure the secret key is in the key set. This prevents transaction malleability at.tacks as described in ([Bern], c.f. section on “small subgroup attacks”). This is part of the GEN algorithm as described in ([CN], 4.4).
4.3.4 check_key
Inputs a public key and outputs if the point is on the curve.
4.3.5 secret_key_to_public_key
Inputs a secret key, checks it for some uniformity conditions, and outputs the cor.responding public key, which is essentially just 8 times the base point times the point.
4.3.6 hash_to_ec
Inputs a key, hashes it, and then does the equivalent in bitwise operations of mul.tiplying the resulting integer by the base point and then by 8.
4.3.7 generate_key_image
Takes as input a secret key x and public key P , and returns I = xHp (P ), the key image. This is part of the GEN algorithm as described in ([CN], 4.4).
4.3.8 generate_ring_signature
Computes a ring signature, performing SIG as in ([CN], 4.4) given a key image I, a list of n public keys Pi, and a secret index. Essentially there is a loop on i, and if the secret-index is reached, then an if-statement controls the special computation of Li,Ri when i is equal to the secret index. The values ci and ri for the signature are computed throughout the loop and returned along with the image to create the total signature (I,c1, ..., cn,r1, ..., rn) .
4.3.9 check_ring_signature
Runs the VER algorithm in ([CN], 4.4). The verifier uses a given ring signature n
to compute L ' i = riGi, Ri ' = riHp (Pi)+ ciI, and finally to check ifi=0 ci = Hs (m, L 0' , ..., L ' ,R 0' , ..., R ' ) mod l.nn
4.3.10 generate_key_derivation
Takes a secretkey b,andapublic key P , and outputs 8·bP . (The 8 being for thepur.pose of the secret key set, as described in 4.3.3). This is used in derive_public_key as part of creating one-time addresses.
4.3.11 derivation_to_scalar
Performs Hs (.) as part of generating keys in ([CN], 4.3, 4.4). It hashes an output index together with the point.
4.3.12 derive_public_key
Takes a derivation rA (computed via generate_key_derivation), a point B, and an output index, computes a scalar via derivation_to_scalar, and then computes Hs (rA)+ B.
4.3.13 generate_signature
This takes a prefix, a public key, and a secret key, and generates a standard (not ring) transaction signature (similar to a Bitcoin transaction signature).
4.3.14 check_signature
This checks if a standard (not ring) signature is a valid signature.
5 Conclusion
Despite the ring signature functions in the original CryptoNote source being poorly commented, the code can be traced back to established and used sources, and is rel.atively straightfoward. The Python implementation provided with this review gives further indication of the code’s correctness. Furthermore, the elliptic curve mathe.matics underlying the ring signature scheme has been extremely well-studied; the concept of ring signatures is not novel, even if their application to cryptocurrencies is.
References
BBJLP. Bernstein, Daniel J., et al. "Twisted edwards curves." Progress in Cryptology–AFRICACRYPT 2008. Springer Berlin Heidelberg, 2008. 389-405. BCPM. Bos, Joppe W., et al. "Selecting Elliptic Curves for Cryptography: An E.ciency and Security Analysis." IACR Cryptology ePrint Archive 2014 (2014): 130. Bern. Bernstein, Daniel J. "Curve25519: new Di.e-Hellman speed records." Public Key Cryptography-PKC 2006. Springer Berlin Heidelberg, 2006. 207-228. CH. Chaum, David, and Eugene Van Heyst. "Group signatures." Advances in Cryptology—EUROCRYPT’91. Springer Berlin Heidelberg, 1991. CN. van Saberhagen, Nicolas. "CryptoNote v 2.0." (2013). FIPS. SHA, NIST DRAFT. "standard: Permutation-based hash and extendable-output functions." DRAFT FIPS 202 (2014).
Fu. Fujisaki, Eiichiro. "Sub-linear size traceable ring signatures without random oracles." IEICE TRANSACTIONS on Fundamentals of Electronics, Communications and Computer Sciences 95.1 (2012): 151-166.
FS. Fujisaki, Eiichiro, and Koutarou Suzuki. "Traceable ring signature." Public Key Cryptography–PKC 2007. Springer Berlin Heidelberg, 2007. 181-200.
IAN. IANIX
http://ianix.com/pub/curve25519-deployment.html Si. Silverman, Joseph H. The arithmetic of elliptic curves. Vol. 106. Dordrecht: Springer, 2009.
SN.
http://lab.monero.cc/pubs/multiple_equations_attack.pdf
