Add privacy-first, self-hosted analytics (GoatCounter)

This commit is contained in:
null 2021-02-23 15:39:17 +01:00
parent febc0fc379
commit 8cb19994bf
58 changed files with 72 additions and 417 deletions

View file

@ -1,60 +0,0 @@
https://www.reddit.com/r/Bitcoin/comments/8dr4fw/benedikt_b%C3%BCnz_bulletproofs/dxpv4q6/
Pieter Wuille on Bulletproofs:
Bulletproofs is a general technology to implement zero-knowledge proofs.
Bitcoin does not use zero-knowledge proofs. There is no way you can just "plug in" Bulletproofs anywhere in Bitcoin.
Perhaps you are talking about confidential transactions (CT). This is a technique to permit a public ledger that makes the amounts hidden while still permitting everyone to verify the balances adds up. If that sounds like magic, that's because it is.
CT rely on zero-knowledge proofs. They could use Bulletproofs. They could also use other types of zero-knowledge proofs (there are several, zk-SNARKS is the well known, each with their own trade-offs). Certainly the invention of Bulletproofs made CT more accessible.
However... CT is still very different from how Bitcoin works right now. There is no obvious way to integrate them. My best hope would be using something like an extension block, where you can have coins on the "legacy" side or coins on the confidential side - with explicit operations to move them between the two.
However, that is far from simple, and AFAIK nobody is really working on it. Much as I love this technique and would be very excited to see it in Bitcoin, it's unrealistic to think that it will be usable anytime soon there.
Every system must lack at least one of unconditional soundness and unconditional blindness. It's perfectly possible to build a system that lacks both.
Bulletproofs are a general zero-knowledge proof technique. That means that they can be used to prove any statement over secret data without revealing that data.
You could prove you know 2 numbers that add up to 7.
You could prove that you know a string whose SHA256 hash is 16c28109a2719ebd4a123db11ff966f02d814354e3dc932449484f1c5a804af4, without revealing anything else about that string.
They could be used instead of zk-SNARKs in Zero-Knowledge Contingent Payments (swapping money for solutions to a problem). These can be done without any changes to Bitcoin.
You could (in theory, read on) use them to build a blockchain similar to ZCash (which heavily relies on zk-SNARKs for proving that their ledger makes sense), but without the trusted setup procedure or novel cryptography (Bulletproofs use very conservative security assumptions). Unfortunately, Bulletproof validation is much slower than zk-SNARK validation for complex problems, so it's not really comparable.
I expect that the most interesting applications are things we haven't considered yet. They suddenly bring zero-knowledge proofs into scope for a lot of problems and protocols where it wasn't really reasonable to go through the effort of using one of the existing proof systems.
++++
I'm pretty sure that Monero is not unconditionally sound. Even if it is, after switching to Bulletproofs they won't be (Bulletproofs cannot be made unconditionally sound).
Yes, with the old rangeproof construction there was an alternative that was unconditionally sound, but not unconditionally private.
This is not possible with Bulletproofs (and theoretically impossible with anything with similar compactness; unconditionally sound proofs cannot be small).
++++
Bulletproofs are a general zero-knowledge proof technique. That means that they can be used to prove any statement over secret data without revealing that data.
You could prove you know 2 numbers that add up to 7.
You could prove that you know a string whose SHA256 hash is 16c28109a2719ebd4a123db11ff966f02d814354e3dc932449484f1c5a804af4, without revealing anything else about that string.
They could be used instead of zk-SNARKs in Zero-Knowledge Contingent Payments (swapping money for solutions to a problem). These can be done without any changes to Bitcoin.
You could (in theory, read on) use them to build a blockchain similar to ZCash (which heavily relies on zk-SNARKs for proving that their ledger makes sense), but without the trusted setup procedure or novel cryptography (Bulletproofs use very conservative security assumptions). Unfortunately, Bulletproof validation is much slower than zk-SNARK validation for complex problems, so it's not really comparable.
I expect that the most interesting applications are things we haven't considered yet. They suddenly bring zero-knowledge proofs into scope for a lot of problems and protocols where it wasn't really reasonable to go through the effort of using one of the existing proof systems.
++++
Practical zero-knowledge proofs have existed for a few years now, and ZKCPs are indeed an application of them.
Bulletproofs are just a new type of zero-knowledge proof. Compared to zk-SNARKS, they're much more conservative in their security assumptions, and don't need a complicated setup procedure before proofs can be created. On the other hand, they're also larger and slower for complicated problsms. And they don't do anything that couldn't be done before - they're just more practical depending on your requirements.

View file

@ -1,32 +0,0 @@
https://www.reddit.com/r/Bitcoin/comments/8dr4fw/benedikt_b%C3%BCnz_bulletproofs/dxpv4q6/
Pieter Wuille on CT:
In a system that uses CT, if someone finds a break in the fundamental security of elliptic curve cryptography (ECC), he can print money. Worse, because the amounts are all private, he can do so undetectably. That's an existential threat for a currency which has controlled inflation as prime goal.
Such a break would be dangerous for Bitcoin (even without CT) regardless, as it relies on ECC for protecting against theft. However, Bitcoin can migrate to use a different signature scheme if necessary. It would be chaotic, but not necessarily pose an existential risk.
There are people who agree with this perspective. It's a mathematical fact that any privacy system that hides amounts and is built on top of ECC will at least have one of the properties below:
An ECC break will permit printing money undetectaby.
An ECC break will permit deanonymizing amounts in the historical chain.
In other words:
An ECC break means the currency can undetectably be inflated (going forward).
An ECC break means the ledger's history can retroactively be deanonymized (goin backward).
So we are faced with a choice between those two regardless if we want better privacy. Some people believe the second is worse than the first, and choosing the first actually allows for more efficient technology. This is a choice that Zcash, Monero, Grin, all make. CT with Bulletproofs would do the same.
However, regardless of your own opinion in this matter, Bitcoin's evolution is a large collaborative process, where such fundamental changes need buy-in from large parts of the ecosystem. My fear is that the question of giving up the ability to exactly audit the monetary supply is going to make it hard to make CT acceptable.
Furthermore, there are other challenges. CT makes transactions larger, slower to verify, and poses a very significant engineering challenge to incorporate into Bitcoin without breaking backward compatibility.
++++
> Also, is there any possible system that can have unconditional soundness and privacy at the same time (something other than ECC obviously)?
No, that's mathematically impossible.

View file

@ -1,18 +0,0 @@
Pieter Wuille on CT:
In a system that uses CT, if someone finds a break in the fundamental security of elliptic curve cryptography (ECC), he can print money. Worse, because the amounts are all private, he can do so undetectably. That's an existential threat for a currency which has controlled inflation as prime goal.
Such a break would be dangerous for Bitcoin (even without CT) regardless, as it relies on ECC for protecting against theft. However, Bitcoin can migrate to use a different signature scheme if necessary. It would be chaotic, but not necessarily pose an existential risk.
There are people who agree with this perspective. It's a mathematical fact that any privacy system that hides amounts and is built on top of ECC will at least have one of the properties below:
An ECC break will permit printing money undetectaby.
An ECC break will permit deanonymizing amounts in the historical chain.
So we are faced with a choice between those two regardless if we want better privacy. Some people believe the second is worse than the first, and choosing the first actually allows for more efficient technology. This is a choice that Zcash, Monero, Grin, all make. CT with Bulletproofs would do the same.
However, regardless of your own opinion in this matter, Bitcoin's evolution is a large collaborative process, where such fundamental changes need buy-in from large parts of the ecosystem. My fear is that the question of giving up the ability to exactly audit the monetary supply is going to make it hard to make CT acceptable.
Furthermore, there are other challenges. CT makes transactions larger, slower to verify, and poses a very significant engineering challenge to incorporate into Bitcoin without breaking backward compatibility.

View file

@ -1,21 +0,0 @@
### TODO
payment_id
payments <PID_1> [<PID_2> ... <PID_N>]
print_ring <key_image> | <txid>
save_known_rings
save_watch_only
set <option> [<value>]
set_daemon <host>[:<port>] [trusted|untrusted]
set_log <level>|{+,-,}<categories>
set_ring <filename> | ( <key_image> absolute|relative <index> [<index>...])
set_tx_note <txid> [free text note]
sign_transfer [export_raw]
submit_transfer
sweep_all [index=<N1>[,<N2>,...]] [<priority>] [<ring_size>] [outputs=<N>] <address> [<payment_id>]
sweep_below <amount_threshold> [index=<N1>[,<N2>,...]] [<priority>] [<ring_size>] <address> [<payment_id>]
sweep_single [<priority>] [<ring_size>] [outputs=<N>] <key_image> <address> [<payment_id>]
transfer [index=<N1>[,<N2>,...]] [<priority>] [<ring_size>] (<URI> | <address> <amount>) [<payment_id>]
locked_transfer [index=<N1>[,<N2>,...]] [<priority>] [<ring_size>] (<URI> | <addr> <amount>) <lockblocks> [<payment_id>]

View file

@ -1 +0,0 @@
https://monero.stackexchange.com/questions/1/how-do-the-monero-nodes-find-each-other

View file

@ -1,8 +0,0 @@
---
title: Pedersen Commitment
---
# Pedersen Commitment
https://www.reddit.com/r/Monero/comments/9ed7vb/pedersen_commitment/
https://monero.stackexchange.com/questions/10177/who-generates-parameters-g-h-for-pedersen-commitment-in-monero

View file

@ -1,13 +0,0 @@
# Risks of using remote node
https://monero.stackexchange.com/questions/38/what-privacy-or-security-trade-offs-are-associated-with-not-running-your-own-ful/
https://monero.stackexchange.com/questions/1482/how-much-information-is-passed-from-the-daemon-to-simplewallet-when-scanning-for?rq=1%20
https://monero.stackexchange.com/questions/1134/is-it-safe-to-share-a-daemon-with-a-roommate?noredirect=1&lq=1
## Reference
* [Reddit answer](https://www.reddit.com/r/Monero/comments/3jhyqc/0mq_help_share_this_exciting_news/)
* [SE 1](https://monero.stackexchange.com/questions/1482/how-much-information-is-passed-from-the-daemon-to-simplewallet-when-scanning-for?rq=1)
* [SE 2](https://monero.stackexchange.com/questions/1134/is-it-safe-to-share-a-daemon-with-a-roommate?noredirect=1&lq=1)

View file

@ -1,77 +0,0 @@
---
title: Stealth Address
---
# Stealth Address
## Hides recipient
Stealth address is a privacy technique to hide the recipient.
Even though blockchain is public, observer has no way to link the payment to the recipient.
Payments simply do **not** go to recipient address. Instead payments go to one-time "stealth" addresses.
## One-time, per payment
Stealth address is generated for each individual payment and must not be reused.
In Bitcoin, should stealth address be reused, the payments are linked.
Observer would learn these payments were to the same person.
This wouldn't be end of the world though, as most users would link the outputs anyway when spending from the wallet.
In Monero, stealth address reuse leads to lose of funds.
If sender re-uses stealth address, then recipient will only be able to claim one of the payments.
See [key image](/cryptography/asymmetric/key-image) to learn why this is the case.
Practically, to re-use stealth address, sender would have to manually craft a malicious transaction.
Recipient would simply not acknowledge receiving the payment, as if sender never paid.
## Wallet level feature
Stealth addresses are not part of the consensus layer. For transaction to be valid,
it does not matter how the key pairs were generated.
Stealth address is non-interactive protocol between sender and recipient.
## Elliptic curves magic properties
Before going further understand the following properties of elliptic curves.
Once you internalize these critical properties,
you will be able to easily come up with a stealth address scheme yourself.
### It is possible to establish a shared secret without sharing a secret
Two parties can come up with the same secret number w/o sending anything except their public keys.
Specifically, having 2 unrelated key pairs, you can exchange public keys, and then each party can independently calculate the same secret number, simply by multiplying own private key with other party's public key:
`s = aB = bA`, where:
* s - the secret (256-bit number)
* a - Alice private key
* A - Alice public key
* b - Bob private key
* B - Bob public key
### A new key pair can be derived by multiplying both keys
Having a key pair, you can derive a new key pair, simply by multiplying both keys by an integer.
Surprisingly, the new key pair will be valid, i.e. the private key will match the public key.
## Stealth address protocol
1. Sender Alice generates a new key pair. Note this is entirely local to the sender.
* a - private key
* A - public key
2. Sender Alice gets receiver's (Bob) public key from his address, `B`.
3. Sender calculates the secret:
`s = rB`
## Reference
http://www.scitepress.org/DigitalLibrary/Link.aspx?doi=10.5220/0006270005590566

View file

@ -1,7 +0,0 @@
---
title: Transaction
---
# Monero transaction
https://monero.stackexchange.com/questions/2136/understanding-the-structure-of-a-monero-transaction?noredirect=1&lq=1
https://monero.stackexchange.com/questions/6736/how-does-input-reference-the-output-of-some-transaction?noredirect=1&lq=1

View file

@ -6,4 +6,4 @@
worker: "assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -6,4 +6,4 @@
worker: "../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -14,4 +14,4 @@
worker: "../../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -6,4 +6,4 @@
worker: "../../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -9,4 +9,4 @@
worker: "../../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -6,4 +6,4 @@
worker: "../../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -7,4 +7,4 @@
worker: "../../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -6,4 +6,4 @@
worker: "../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -6,4 +6,4 @@
worker: "../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -6,4 +6,4 @@
worker: "../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -6,4 +6,4 @@
worker: "../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -6,4 +6,4 @@
worker: "assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -44,4 +44,4 @@ testpoints.moneropulse.co
worker: "../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -6,4 +6,4 @@
worker: "../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -28,4 +28,4 @@ PORT STATE SERVICE
worker: "../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -6,4 +6,4 @@
worker: "../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -6,4 +6,4 @@
worker: "../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -6,4 +6,4 @@
worker: "../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -53,4 +53,4 @@ log-file=/tmp/monero-wallet-cli.log
worker: "../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -6,4 +6,4 @@
worker: "../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -6,4 +6,4 @@
worker: "../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -901,4 +901,4 @@ curl <span class=se>\</span>
worker: "../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -12,4 +12,4 @@ tail -f ~/.bitmonero/bitmonero.log # watch the logs
worker: "../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -37,4 +37,4 @@ extras/monero-blockchain-depth
worker: "../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -20,4 +20,4 @@ grep $file_hash /tmp/reference-hashes.txt
worker: "../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -11,4 +11,4 @@ show_transfers
worker: "../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -6,4 +6,4 @@
worker: "../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -6,4 +6,4 @@
worker: "../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -6,4 +6,4 @@
worker: "../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -6,4 +6,4 @@
worker: "../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -6,4 +6,4 @@
worker: "../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -6,4 +6,4 @@
worker: "../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -6,4 +6,4 @@
worker: "../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -9,4 +9,4 @@
worker: "../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -6,4 +6,4 @@
worker: "../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

View file

@ -112,4 +112,4 @@ tcp 0 0 127.0.0.1:9050 0.0.0.0:* LISTEN
worker: "../../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

File diff suppressed because one or more lines are too long

View file

@ -1,139 +1,139 @@
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"><url>
<loc>https://monerodocs.org/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/interacting/download-monero-binaries/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/interacting/verify-monero-binaries/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/interacting/overview/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/interacting/monero-config-file/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/interacting/monerod-reference/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/interacting/monero-wallet-cli-reference/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/interacting/monero-wallet-gui-reference/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/interacting/monero-wallet-rpc-reference/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/interacting/monero-blockchain-export-reference/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/interacting/monero-blockchain-import-reference/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/technical-specs/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/cryptography/introduction/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/cryptography/asymmetric/introduction/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/cryptography/asymmetric/private-key/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/cryptography/asymmetric/public-key/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/cryptography/asymmetric/edwards25519/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/cryptography/asymmetric/key-image/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/cryptography/base58/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/cryptography/prng/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/cryptography/keccak-256/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/public-address/standard-address/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/public-address/subaddress/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/public-address/integrated-address/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/proof-of-work/what-is-pow/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/proof-of-work/pow-in-cryptocurrencies/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/proof-of-work/cryptonight/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/proof-of-work/random-x/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/multisignature/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/infrastructure/networks/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/infrastructure/tor-onion-p2p-seed-nodes/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/infrastructure/monero-pulse/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/running-node/open-node-tor-onion/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url><url>
<loc>https://monerodocs.org/accepting-monero/overview/</loc>
<lastmod>2021-01-27</lastmod>
<lastmod>2021-02-23</lastmod>
<changefreq>daily</changefreq>
</url>
</urlset>

Binary file not shown.

View file

@ -6,4 +6,4 @@
worker: "../assets/javascripts/worker/search.8c7e0a7e.min.js"
}, typeof search !== "undefined" && search)
})
</script> </body> </html>
</script> <script data-goatcounter=https://gc.monerodocs.org/count async src=https://gc.monerodocs.org/count.js></script> </body> </html>

File diff suppressed because one or more lines are too long

View file

@ -1,18 +0,0 @@
Pieter Wuille on CT:
In a system that uses CT, if someone finds a break in the fundamental security of elliptic curve cryptography (ECC), he can print money. Worse, because the amounts are all private, he can do so undetectably. That's an existential threat for a currency which has controlled inflation as prime goal.
Such a break would be dangerous for Bitcoin (even without CT) regardless, as it relies on ECC for protecting against theft. However, Bitcoin can migrate to use a different signature scheme if necessary. It would be chaotic, but not necessarily pose an existential risk.
There are people who agree with this perspective. It's a mathematical fact that any privacy system that hides amounts and is built on top of ECC will at least have one of the properties below:
An ECC break will permit printing money undetectaby.
An ECC break will permit deanonymizing amounts in the historical chain.
So we are faced with a choice between those two regardless if we want better privacy. Some people believe the second is worse than the first, and choosing the first actually allows for more efficient technology. This is a choice that Zcash, Monero, Grin, all make. CT with Bulletproofs would do the same.
However, regardless of your own opinion in this matter, Bitcoin's evolution is a large collaborative process, where such fundamental changes need buy-in from large parts of the ecosystem. My fear is that the question of giving up the ability to exactly audit the monetary supply is going to make it hard to make CT acceptable.
Furthermore, there are other challenges. CT makes transactions larger, slower to verify, and poses a very significant engineering challenge to incorporate into Bitcoin without breaking backward compatibility.

File diff suppressed because one or more lines are too long

View file

@ -1,21 +0,0 @@
### TODO
payment_id
payments <PID_1> [<PID_2> ... <PID_N>]
print_ring <key_image> | <txid>
save_known_rings
save_watch_only
set <option> [<value>]
set_daemon <host>[:<port>] [trusted|untrusted]
set_log <level>|{+,-,}<categories>
set_ring <filename> | ( <key_image> absolute|relative <index> [<index>...])
set_tx_note <txid> [free text note]
sign_transfer [export_raw]
submit_transfer
sweep_all [index=<N1>[,<N2>,...]] [<priority>] [<ring_size>] [outputs=<N>] <address> [<payment_id>]
sweep_below <amount_threshold> [index=<N1>[,<N2>,...]] [<priority>] [<ring_size>] <address> [<payment_id>]
sweep_single [<priority>] [<ring_size>] [outputs=<N>] <key_image> <address> [<payment_id>]
transfer [index=<N1>[,<N2>,...]] [<priority>] [<ring_size>] (<URI> | <address> <amount>) [<payment_id>]
locked_transfer [index=<N1>[,<N2>,...]] [<priority>] [<ring_size>] (<URI> | <addr> <amount>) <lockblocks> [<payment_id>]

File diff suppressed because one or more lines are too long

File diff suppressed because one or more lines are too long

File diff suppressed because one or more lines are too long

File diff suppressed because one or more lines are too long

File diff suppressed because one or more lines are too long