From 8cb19994bf5adb057e006bd1f861471b17834924 Mon Sep 17 00:00:00 2001 From: null Date: Tue, 23 Feb 2021 15:39:17 +0100 Subject: [PATCH] Add privacy-first, self-hosted analytics (GoatCounter) --- docs/todo/bulletproofs.md | 60 -------------- docs/todo/confidential-transactions.md | 32 -------- docs/todo/confidential-transactions.txt | 18 ---- .../monero-wallet-cli__remaining_commands.txt | 21 ----- docs/todo/p2p.md | 1 - docs/todo/pedersen-commitment.md | 8 -- docs/todo/risks-of-using-remote-node.md | 13 --- docs/todo/stealth-address.md | 77 ------------------ docs/todo/tx.md | 7 -- public/404.html | 2 +- public/accepting-monero/overview/index.html | 2 +- .../asymmetric/edwards25519/index.html | 2 +- .../asymmetric/introduction/index.html | 2 +- .../asymmetric/key-image/index.html | 2 +- .../asymmetric/private-key/index.html | 2 +- .../asymmetric/public-key/index.html | 2 +- public/cryptography/base58/index.html | 2 +- public/cryptography/introduction/index.html | 2 +- public/cryptography/keccak-256/index.html | 2 +- public/cryptography/prng/index.html | 2 +- public/index.html | 2 +- public/infrastructure/monero-pulse/index.html | 2 +- public/infrastructure/networks/index.html | 2 +- .../tor-onion-p2p-seed-nodes/index.html | 2 +- .../download-monero-binaries/index.html | 2 +- .../index.html | 2 +- .../index.html | 2 +- .../interacting/monero-config-file/index.html | 2 +- .../monero-wallet-cli-reference/index.html | 2 +- .../monero-wallet-gui-reference/index.html | 2 +- .../monero-wallet-rpc-reference/index.html | 2 +- .../interacting/monerod-reference/index.html | 2 +- public/interacting/overview/index.html | 2 +- .../verify-monero-binaries/index.html | 2 +- public/multisignature/index.html | 2 +- public/proof-of-work/cryptonight/index.html | 2 +- .../pow-in-cryptocurrencies/index.html | 2 +- public/proof-of-work/random-x/index.html | 2 +- public/proof-of-work/what-is-pow/index.html | 2 +- .../integrated-address/index.html | 2 +- public/public-address/main-address/index.html | 2 +- .../standard-address/index.html | 2 +- public/public-address/subaddress/index.html | 2 +- .../index.html | 2 +- .../open-node-tor-onion/index.html | 2 +- public/search/search_index.json | 2 +- public/sitemap.xml | 68 ++++++++-------- public/sitemap.xml.gz | Bin 560 -> 560 bytes public/technical-specs/index.html | 2 +- public/todo/bulletproofs/index.html | 9 -- public/todo/confidential-transactions.txt | 18 ---- .../todo/confidential-transactions/index.html | 15 ---- .../monero-wallet-cli__remaining_commands.txt | 21 ----- public/todo/p2p/index.html | 9 -- public/todo/pedersen-commitment/index.html | 9 -- .../risks-of-using-remote-node/index.html | 9 -- public/todo/stealth-address/index.html | 9 -- public/todo/tx/index.html | 9 -- 58 files changed, 72 insertions(+), 417 deletions(-) delete mode 100644 docs/todo/bulletproofs.md delete mode 100644 docs/todo/confidential-transactions.md delete mode 100644 docs/todo/confidential-transactions.txt delete mode 100644 docs/todo/monero-wallet-cli__remaining_commands.txt delete mode 100644 docs/todo/p2p.md delete mode 100644 docs/todo/pedersen-commitment.md delete mode 100644 docs/todo/risks-of-using-remote-node.md delete mode 100644 docs/todo/stealth-address.md delete mode 100644 docs/todo/tx.md delete mode 100644 public/todo/bulletproofs/index.html delete mode 100644 public/todo/confidential-transactions.txt delete mode 100644 public/todo/confidential-transactions/index.html delete mode 100644 public/todo/monero-wallet-cli__remaining_commands.txt delete mode 100644 public/todo/p2p/index.html delete mode 100644 public/todo/pedersen-commitment/index.html delete mode 100644 public/todo/risks-of-using-remote-node/index.html delete mode 100644 public/todo/stealth-address/index.html delete mode 100644 public/todo/tx/index.html diff --git a/docs/todo/bulletproofs.md b/docs/todo/bulletproofs.md deleted file mode 100644 index 2abe560..0000000 --- a/docs/todo/bulletproofs.md +++ /dev/null @@ -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. diff --git a/docs/todo/confidential-transactions.md b/docs/todo/confidential-transactions.md deleted file mode 100644 index d330dc6..0000000 --- a/docs/todo/confidential-transactions.md +++ /dev/null @@ -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. diff --git a/docs/todo/confidential-transactions.txt b/docs/todo/confidential-transactions.txt deleted file mode 100644 index 2ff0b8f..0000000 --- a/docs/todo/confidential-transactions.txt +++ /dev/null @@ -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. diff --git a/docs/todo/monero-wallet-cli__remaining_commands.txt b/docs/todo/monero-wallet-cli__remaining_commands.txt deleted file mode 100644 index efdeeff..0000000 --- a/docs/todo/monero-wallet-cli__remaining_commands.txt +++ /dev/null @@ -1,21 +0,0 @@ - -### TODO - - payment_id - payments [ ... ] - print_ring | - save_known_rings - save_watch_only - set