Bitcoin the network is fully transparent, which makes BTC not really fungible - it can and is traced, which creates better/worse BTC. This is why coinbase (small c) BTC is sold at premium.
Bitcoin should and will die, but in its place a thousand flowers will bloom.
FYI, you can have BTC asset without Bitcoin network in trust-less manner TODAY. See recent paper by Leona Hioki on the way to do it using Witness Encryption cryptographic scheme.
Financial privacy is a must-have, not a nice-to-have feature. Financial privacy does not prevent one from being able to pay taxes. But it definitely prevents this type of attacks.
It gets used. Because this secret chat does not save its history, it leaves no trace on the devive. So people who want to cheat on their partner, but know that their partner checks their mobile at times even installed telegram because of this feature (and they do not know what e2e means).
Surprisingly many people have this motivation. So many, that I know of persons who got problems with installing telegram, because their partner assumed - it was for this reason.
> I don’t quite understand what the point of telegram is then?
It's UX is far superior to any cross-platform competitor. On top of that, its client is open source and the servers have easy and free bot APIs. It also has channels, which broadcast your messages to followers and many secure competitors don't have such functionality.
It's not encrypted, but as it turns out most people don't really care about that in practice. If they would, texting wouldn't be popular in places like the USA. That's probably why people go to Telegram instead of Signal, ease of use is more important than privacy for most, especially in group chats that are generally about what's for dinner.
There are multiple ways of pulling this off. Signatures are zk-proof systems, just a very specialized ones. So you do it every time you sign a message.
Why would it? Both signatures and snarks are non-interactive. And since you prove any(*) computation with a snark, you can prove that computation that verifies something (signature or snark proof) went well.
Without the interactive check imagine the real finder crewtes a self signed version of "42" for 2020. Shortly after an fake finder creates a new document with the exact same contents "42" dated 2019 and self signed. There is no interactive way of verifying which was truly the original here, you'd need to bring in a trusted 3rd party (or have already trusted one of the signers over the other in the first place) which is an interactive verification step (and actually measures when it was validated with 3rd party not truly when it was discovered).
I think we are talking about three different scenarios.
You are describing attribution problem. "Solution to the puzzle is no longer a secret, it is a public knowledge. Who was the original finder?". This problem is not really concerned with the proof - there is nothing more to hide, milk has been spilled.
GP is speaking about a different problem. Thief is not stealing the secret - they are stealing the proof that secret exists. In GP's scenario thief hacks GP's machine - which is not necessary, since GP is likely to show the proof to the world himself.
> That means if someone snoops my machine and tries to use my proof to claim that they know the answer, I can spot it as a stolen proof. However, without revealing the treasure, I wouldn't be able to prove that they stole it, because it is equally possible that I stole it from them.
And I was specifically addressing the situation when GP has made proof public. In such scenario thief can point the finger at the proof and claim that they have produced it. Solution described by me prevents thief from doing it, since proof will contain a public key from a keypair thief does not possess.
> You are describing attribution problem. "Solution to the puzzle is no longer a secret, it is a public knowledge. Who was the original finder?".
Not at all, though perhaps my choice of "42" was poor as that seems to be an actual answer to one of the examples used here. "42" was meant as a dummy proof of knowledge value, not the secret value. My bad, should have picked something more obvious.
> GP is speaking about a different problem. Thief is not stealing the secret - they are stealing the proof that secret exists. In GP's scenario thief hacks GP's machine - which is not necessary, since GP is likely to show the proof to the world himself.
Yes, this is the scenario I'm exclusively referring to.
> And I was specifically addressing the situation when GP has made proof public. In such scenario thief can point the finger at the proof and claim that they have produced it. Solution described by me prevents thief from doing it, since proof will contain a public key from a keypair thief does not possess.
Your solution gives proof the person claiming to have found the proof signed their copy of the proof before the time it was shared, it doesn't prevent a 2nd person from taking the ZKP that was signed, making a new copy of it's value (not signature history), and signing it as an original signed ZK proof and claiming to have found it even earlier. The only ways I know of to detect such forgery of an original signed document occurred all involve interactivity (which makes the problem trivial).
Embedding the user's public key in the ZKP process is also an interactive ZKP method, as above interactive verifications are trivial and there are many ways. The example site here uses non-interactive zero-knowledge proofs via zk-SNARK and that's where the open question left in my original comment lay.
The trick is to sign the secret, not the proof. And than to prove inside the circuit following claims:
1) secret (provided as a hidden input) is correct a solution to the puzzle
2) signature that signs the secret is correct (signature is provided as a hidden input)
3) signature corresponds to a public key (which is provided as a public input)
You don't need blockchain or interaction for that. You just provide the proof and you are done. As long as other people are not able to steal the secret and your private key - world knows that you are the only holder of the secret.
1) pepesza signs the ZKP "42424242" as the correct solution to the problem in 2022
2) pepesza's signature is correct
3) pepesza's signature corresponds to a public key
4) zamadatix see's pepesza's signed ZKP value and creates a signs it as a "new" ZKP value "42424242" as the correct solution to the problem and dates it as 2021
5) zamadatix's signature is correct
6) zamadatix's signature corresponds to a public key
7) nobody can tell whether pepesza's or zamadatix's signed version of the solution actually came first without interaction, just that each claims to have signed it at the specified times.
How do you work around 7)? Alternatively if the signature instead hides the actual value of the ZKP:
1) pepesza signs the ZKP "424242" in a way that hides what that value is or otherwise prevents it from being read without further interaction.
2) pepesza's signature is correct
3) pepesza's signature corresponds to a public key
4) nobody can verify what pepesza has signed is actually a valid ZKP as they can't read the value to check and they can't interact with pepesza or they are back to an interactive ZKP
In the first scenario you haven't proven you generated it first without interaction you've just proven you signed that you claimed to have generated it first. In the second scenario you have broken the ability for anyone to validate you have an answer as they can't read your ZKP value. If you wait for someone to challenge you and then show them that's an interaction.
Is there a way I'm missing that avoids 7) in scenario 1 or 4) in scenario 2 or an alternative scenario completely?
1) pepesza finds "42424242" <- that is the solution that needs to be hidden from the world
2) Signature = sign("42424242", privk_pepesza)
3) Witness = Circuit("42424242", Signature, pubk_pepesza). `Circuit` program will validate things I've mentioned. a) is 42424242 a correct solution to the puzzle? b) is signature correct for "42424242" as msg and pubk_pepesza as signer? It will return a computation trace - the Witness.
4) Proof = Prove(Witness). This `Prove` program is specific to a zksnark flavor that is being used. Some flavors will produce Proof of constant size.
Now pepesza sends the Proof and pubk_pepesza to zamadatix. Zamadatix runs:
Result = Validate(Proof, pubk_pepesza). If Result is true, both a) and b) are correct. This allows zamadatix to learn if pepesza actually has a solution to the puzzle. Note that Validate(Proof, pubk_zamadatix) will return false.
`Validate` is the program which can be automatically compiled from the Circuit (and things that are dependent on the flavor of zksnarks used).
The whole thing revolves around two properties of zksnarks. First - they allow to prove any(*) computation. Second - they allow to use so-called hidden inputs. In example above `pubk_pepesza` is the only public input. "42424242" and Signature are both hidden inputs and don't have to be revealed. Thus Zamadatix can create a Proof' that will result in true = Validate(Proof', pukb_zamadatix), but that would require an independent discovery of "42424242" string. Or a hack of pepesza's machine.
Sign the puzzle solution with your private key. Check signature inside the circuit. This obviously can't be applied to this particular game since it has a circuit that does not employ such measures. Alternatively, if used snark is recursive - create a new circuit that will both validate original proof and check the signature.
Think of Kessler syndrome. One can imagine that blowing (small) N of them would create a cloud of shrapnel posing danger for the whole network. Birds are on really low orbits, so it would clear after some time, but network might not survive this.
I could agree. Coming to Erlang from Elixir, I truly appreciate the simplicity and small size of the Erlang language. Making it possible to write exhaustive documentation. In fact, in Joe's book he defers a lot to the online docs/manual for in-depth treatment of a lot of topics.
Don't give them any info. Write something along the lines of "transfer of money", always. Use separate channel to communicate "why". Every bit of information you give them will be used against you.
He had been collecting the documents for months even before the incident that he says prompted him to blow the whistle. He knew that detailed lists of Chinese targets were not needed to blow the whistle on phone metadata collection, but he grabbed those lists anyway and immediately showed them to the SCMP.
> It's interesting how something which was built on the idea of decentralization by design has given way to a clear power structure, where those who have the sway to control the fate of the technology have largely used it to pursue their own personal enrichment over the health and success of the system as a whole.
Well, as one other commenter mentioned, with regard to Bitcoin miners have essentially become a centralized authority, and their decisions on block-size have made Bitcoin less liquid, and less useful as a currency while making transactions more profitable to them.
Another example would be exchanges: a vast majority of people do not use cryptocurrency in a peer-to-peer fashion, but instead go through a small number of centralized exchanges, which have been known to freeze withdrawals, have been riddled with theft, fraud, and a playback of all the financial schemes dreamed up in the last few centuries which have not yet been regulated against in cryptocurrency (pump and dump, Tether etc.).
On top of that, the crypto media sphere seems to be completely unreliable: I've seen many headlines which are deliberately misleading with the intent of stoking a one-sided, glowing narrative about cryptocurrency (I.e. a crypto startup opens their account at Chase bank and the headline reads: "X Coin Begins Partnership with J.P. Morgan Chase", and related online
communities are heavily moderated to support the official viewpoint while silencing others.
Long story short, when I bought a little bit of Bitcoin to play with a few years ago, I could buy a coffee with it, and I could even make purchases with it on Amazon. Since then it's gotten much less useful to the average user.
> , with regard to Bitcoin miners have essentially become a centralized authority, and their decisions on block-size have made Bitcoin less liquid, and less useful as a currency while making transactions more profitable to them.
>Another example would be exchanges
Interestingly enough, with regards to bitcoin, there was a huge powerplay that happened a couple years ago. And this debate proved who had the real power.
A couple years about, almost every major exchange, bitcoin company, merchant payment processor, and bitcoin miner, wanted increase the bitcoin blocksize, in order to reduce transactions fees to users and help adoption.
(Even though this directly hurt the miners, the miners still wanted it, because they supported adoption. Crazy, I know)
But, this change didn't pass, because the 4 or 5 people who controlled the bitcoin core github repository, and reference client disagreed with the changes, it prevented it from happening.
And this was in spite of the fact that almost every single major player in the space wanted this change.
So crazily enough, the central authorities of the bitcoin protocol, are the couple people who hold the keys to a github repository.
> But, this change didn't pass, because the 4 or 5 people who controlled the bitcoin core github repository, and reference client disagreed with the changes, it prevented it from happening.
This is blatant re-writing of history.
A fork was written, Bitcoin Cash, but most people/miners/companies didn't want to use it. It was widely known and the differences/advantages/disadvantages were discussed ad nauseum for months/years.
A Github repo can't force people to run it's code instead of another.
> And this was in spite of the fact that almost every single major player in the space wanted this change.
So why did they keep running Bitcoin Core instead of the fork?
> So why did they keep running Bitcoin Core instead of the fork?
Because it turns out that controlling a github repo is a very powerful power.
> A fork was written, Bitcoin Cash
This has nothing to do with Bitcoin Cash. This has to do with 2XSegwit. An initiative that was supported by every single major miner, all of the exchanges (coinbase, gemini, kraken, ect), as well as the major merchant payment processors (IE, bitpay, and all the others).
There are statements after statements made by all of these players, where they stated support for it. Unfortunately, it seems like the people who control the bitcoin protocol, the developers, had too much power, though.
Did you disagree that every major miner, and Bitcoin business like coinbase and BitPay, put out messages in support of the 2X Segwit agreement?
The ten MB block size limit lowers the number of transactions that can occur in a single block therefore inflating what miners can charge for a transaction. Increasing the blocksise would require miners to choose to mine a hard fork. See the DAO hack for what can happen with strong governance.
Bitcoin should and will die, but in its place a thousand flowers will bloom.
FYI, you can have BTC asset without Bitcoin network in trust-less manner TODAY. See recent paper by Leona Hioki on the way to do it using Witness Encryption cryptographic scheme.