mirror of
https://github.com/monero-project/monero-site.git
synced 2024-11-17 08:18:03 +00:00
Merge branch 'master' of https://github.com/monero-project/monero-site
This commit is contained in:
commit
ac4f06ef99
3 changed files with 50 additions and 36 deletions
|
@ -5,6 +5,16 @@
|
|||
quote-author: Article 19, The Universal Declaration of Human Rights
|
||||
history: [10th Dan on 2015-11-11, 9th Dan on 2015-11-11, 8th Dan on 2015-01-14, 7th Dan on 2014-12-02, 6th Dan on 2014-08-24, 5th Dan on 2014-08-01, 4th Dan on 2014-07-21]
|
||||
|
||||
- level: 9
|
||||
name: pa
|
||||
amount: 12500
|
||||
history: [8th Dan on 2016-01-01, 9th Dan on 2016-01-01, 7th Dan on 2015-02-25, 6th Dan on 2014-12-30, 5th Dan on 2014-09-18]
|
||||
|
||||
- level: 9
|
||||
name: ajiekceu4
|
||||
amount: 10666
|
||||
history: [9th Dan on 2016-02-03, 8th Dan on 2015-11-4, 7th Dan on 2015-08-31, 6th Dan on 2015-05-11]
|
||||
|
||||
- level: 8
|
||||
name: Lloydimiller4
|
||||
amount: 7800
|
||||
|
@ -12,15 +22,15 @@
|
|||
|
||||
- level: 8
|
||||
name: rpietila
|
||||
amount: 7200
|
||||
amount: 8100
|
||||
quote: We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness.--That to secure these rights, Governments are instituted among Men, deriving their just powers from the consent of the governed, --That whenever any Form of Government becomes destructive of these ends, it is the Right of the People to alter or to abolish it, and to institute new Government---it is their right, it is their duty, to throw off such Government.
|
||||
quote-author: Declaration of Independence
|
||||
history: [8th Dan on 2015-02-23, 7th Dan on 2014-09-04, 6th Dan on 2014-08-23, 5th Dan on 2014-08-01, 4th Dan on 2014-07-16]
|
||||
|
||||
- level: 8
|
||||
name: ajiekceu4
|
||||
amount: 8666
|
||||
history: [8th Dan on 2015-11-4, 7th Dan on 2015-08-31, 6th Dan on 2015-05-11]
|
||||
- level: 7
|
||||
name: antw081
|
||||
amount: 3100
|
||||
history: [7th Dan on 2015-07-16, 6th Dan on 2015-02-23, 5th Dan on 2015-02-10, 4th Dan on 2014-11-25, 3rd Dan on 2014-09-05]
|
||||
|
||||
- level: 7
|
||||
name: antw081
|
||||
|
@ -44,11 +54,6 @@
|
|||
quote-author: Section 10
|
||||
history: [7th Dan on 2014-08-13, 6th Dan on 2014-04-29]
|
||||
|
||||
- level: 7
|
||||
name: pa
|
||||
amount: 2500
|
||||
history: [7th Dan on 2015-02-25, 6th Dan on 2014-12-30, 5th Dan on 2014-09-18]
|
||||
|
||||
- level: 6
|
||||
name: HardwarePal
|
||||
amount: 1000
|
||||
|
@ -63,7 +68,7 @@
|
|||
|
||||
- level: 6
|
||||
name: Medusa13
|
||||
amount: 1280.6
|
||||
amount: 1980.6
|
||||
history: [6th Dan on 2015-01-27, 4th Dan on 2014-11-08, 3rd Dan on 2014-08-26]
|
||||
|
||||
- level: 5
|
||||
|
@ -96,10 +101,10 @@
|
|||
amount: 500
|
||||
history: [5th Dan on 2015-02-04, 4th Dan on 2014-08-18, 3rd Dan on 2014-07-17]
|
||||
|
||||
- level: 5
|
||||
- level: 6
|
||||
name: dnaleor
|
||||
amount: 650.1337
|
||||
history: [5th Dan on 2015-02-23, 4th Dan on 2014-12-17, 3rd Dan on 2014-07-17, 1st Dan on 2014-05-03]
|
||||
amount: 1201.1337
|
||||
history: [6th Dan 0n 2016-02-03, 5th Dan on 2015-02-23, 4th Dan on 2014-12-17, 3rd Dan on 2014-07-17, 1st Dan on 2014-05-03]
|
||||
|
||||
- level: 5
|
||||
name: ajiekceu4
|
||||
|
@ -108,8 +113,8 @@
|
|||
|
||||
- level: 5
|
||||
name: saddambitcoin
|
||||
amount: 500
|
||||
history: [5th Dan on 2015-02-28, 4th Dan on 2014-08-18]
|
||||
amount: 1400
|
||||
history: [6th Dan on 2016-02-06, 5th Dan on 2015-02-28, 4th Dan on 2014-08-18]
|
||||
|
||||
- level: 5
|
||||
name: Quicken
|
||||
|
@ -217,6 +222,11 @@
|
|||
history: [3rd Dan on 2015-02-05]
|
||||
|
||||
- level: 3
|
||||
name: Karl Hungus
|
||||
amount: 180
|
||||
history: [3rd Dan on 2016-01-01]
|
||||
|
||||
- level: 3
|
||||
name: palexander
|
||||
amount: 150
|
||||
history: [3rd Dan on 2015-05-13, 2nd Dan on 2015-04-03]
|
||||
|
|
|
@ -10,8 +10,8 @@ attribution: "<!-- Icon is based on work by Freepik (http://www.freepik.com) and
|
|||
---
|
||||
|
||||
### Crypto-Kingdom
|
||||
An online role playing game with ingame trading system based on cryptocurrency culture. Has monero as native currency.
|
||||
Visit [http://cryptokingdom.me](http://cryptokingdom.me) for more info.
|
||||
A MMORPG with a real-world economy with monero as native currency. You can make trades, start an in-game company or develop real estate on your path to becoming a land baron. And when you're done building your empire, you can sit back, pour a beer and chat with your friends. It's Second Life, Wall Street and social networking rolled into one game.
|
||||
Visit [http://cryptokingdom.me](http://cryptokingdom.me), [Bitcointalk](https://bitcointalk.org/index.php?topic=819073.0) and [Reddit](https://www.reddit.com/r/cryptokingdom) for more info.
|
||||
|
||||
### Monerodice
|
||||
A Monero gambling site.
|
||||
|
|
|
@ -11,26 +11,30 @@ attribution: "<!-- Icon is based on work by Freepik (http://www.freepik.com) and
|
|||
|
||||
(insert that protocol image here)
|
||||
|
||||
Bob wants to spend XMR he received in his account and send it to Carol.
|
||||
How is the transaction made?
|
||||
### Bob wants to spend XMR he received in his account and send it to Carol.
|
||||
|
||||
#### How is the transaction made?
|
||||
|
||||
A: Bob gets access to his "real input" that was send to his "stealth address"
|
||||
1. Bob needs the public key from the transaction that contains the output he received and wants to send - Bob needs to @ECDH this key with his private view key
|
||||
|
||||
1. Bob needs the public key from the transaction that contains the output he received and wants to send - Bob needs to @ECDH this key with his private view key.
|
||||
2. Bob also selects the exact number of the output from the transaction that contains the output he wants to send. The other output(s) in this transaction is/are change (Bob doesn't have the private key for those other outputs) Note: typically, due to @auto-denomination, Bob will have more than one output per transaction that belongs to him.
|
||||
3. Bob needs the "master" private key of his account - private spend key, to be precise
|
||||
4. 1,2 and 3 are used to calculate the private key for the specific output he wants to send. (the public key for the transaction can be calculated from this private key - This is correct, but the public key is also stored on the blockchain.)
|
||||
3. Bob needs the "master" private key of his account - private spend key, to be precise.
|
||||
4. Points A 1,2 and 3 are used to calculate the private key for the specific output he wants to send. (the public key for the transaction can be calculated from this private key - This is correct, but the public key is also stored on the blockchain.)
|
||||
|
||||
B: To protects Carol's identity, Bob will do the folowing to generate a "one time" public key for this transaction, making it impossible for others to link all transactions send to Carol to the same "stealth address"
|
||||
5. Bob generates a random number scalar, this one isn't clear from the graphic at all
|
||||
6. this random number is hashed into the transaction public key the transaction private key, and is scalar mult'd into the transaction public key
|
||||
7. he selects the number associated with the outputs (due to auto-denom) that Carol will receive, the other output(s) is/are change that goes back to Bob.
|
||||
8. he needs the "master" public key from Carol to be able to send it to her stealth address - Carol's public view key
|
||||
9. 6,7 and 8 are used to calculate the public key for the specific outputs he wants to send
|
||||
B: To protects Carol's identity, Bob will do the following to generate a "one time" public key for this transaction, making it impossible for others to link all transactions send to Carol to the same "stealth address"
|
||||
|
||||
C: to "mix" the inputs, Bob creates a ring signature
|
||||
10. He selects the actual public key (+ that output's private key) from the output he wants to send, but he also adds other public keys into the mix.
|
||||
11. to prevent double spending, Bob needs to send a valid "key image" together with the public keys of the outputs (or inputs if you prefer)
|
||||
12. he signs the combination of inputs and the key image with his private key, prooving the key image is valid (Bob owns the private key associated with the key image) and that (somehow? I don't know how this works) one of the public keys is used to generate this key image, but as a spectator of the blockchain, we can't know which of the used outputs is "the real one that is being transferred". His private key and the other chosen public key(s) are used to create a ring signature; they'll be one signature for each input, collectively making a ring signature. The key image is an additional public key computed from the output private key (not public key) that's actually being spent.
|
||||
13. This is the collection of outputs that is signed. He grabbed the "fake ones" from the blockchain. He doesn't need permission from the owners for that. This isn't quite right: those are the outputs that are doing the signing. A hash of the TX prefix is "what" is actually being signed.
|
||||
14. This is the key image he signed. If Bob ever tries to send the same output again, the exact same key image will be generated and thus the double spend will be detected.
|
||||
15. this "ring signature" is added to the transaction containing the publi keys that are used in the transaction and proving Bob's ownership of one of those inputs.
|
||||
1. Bob generates a random number scalar, this one isn't clear from the graphic at all.
|
||||
2. This random number is hashed into the transaction public key the transaction private key, and is scalar mult'd into the transaction public key.
|
||||
3. He selects the number associated with the outputs (due to auto-denom) that Carol will receive, the other output(s) is/are change that goes back to Bob.
|
||||
4. He needs the "master" public key from Carol to be able to send it to her stealth address - Carol's public view key.
|
||||
5. Points B 2,3 and 4 are used to calculate the public key for the specific outputs he wants to send.
|
||||
|
||||
C: to "mix" the inputs, Bob creates a ring signature
|
||||
|
||||
1. He selects the actual public key (+ that output's private key) from the output he wants to send, but he also adds other public keys into the mix.
|
||||
2. To prevent double spending, Bob needs to send a valid "key image" together with the public keys of the outputs (or inputs if you prefer).
|
||||
3. He signs the combination of inputs and the key image with his private key, proving the key image is valid (Bob owns the private key associated with the key image) and that (somehow? I don't know how this works) one of the public keys is used to generate this key image, but as a spectator of the blockchain, we can't know which of the used outputs is "the real one that is being transferred". His private key and the other chosen public key(s) are used to create a ring signature; they'll be one signature for each input, collectively making a ring signature. The key image is an additional public key computed from the output private key (not public key) that's actually being spent.
|
||||
4. This is the collection of outputs that is signed. He grabbed the "fake ones" from the blockchain. He doesn't need permission from the owners for that. This isn't quite right: those are the outputs that are doing the signing. A hash of the TX prefix is "what" is actually being signed.
|
||||
5. This is the key image he signed. If Bob ever tries to send the same output again, the exact same key image will be generated and thus the double spend will be detected.
|
||||
6. This "ring signature" is added to the transaction containing the public keys that are used in the transaction and proving Bob's ownership of one of those inputs.
|
||||
|
|
Loading…
Reference in a new issue