pepesza

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.

Telegram does not have any meaningful e2e encryption (apart from 1-1 on-demand stuff nobody uses). So yes, everything is visible to Telegram.

You are welcome! ZKSnarks are really mind-bending tech and are a lot of fun!

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.

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.

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.

Here is other poster, presenting the solution I spoke of in a clearer way: https://news.ycombinator.com/item?id=30094271

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.

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.

See my other comment on how it can be done.

Does such a mechanism exist?

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.

Coming from Erlang to Elixir - I find Elixir docs lacking in both coverage and terseness.

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.

Technically unfeasible considering how much time he had to go through those docs (likely - very little).

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.

Care to elaborate? Some examples?

Monero, Zcash, Grin. Three designs that are based on different cryptography - all three giving user full privacy.

Visa is very expensive. How about that?

Not all cryptocurrencies add public record. Examples: ZCash, Grin.

They are doing beacon chain (a distributed unbiasable verifiable random number generator, constructed using commit-reveal scheme + VDF to fix commit-reveal biasability) to choose sets of validators for each of the shards. It is not your typical PoS design. I'm not sure how exactly validators for single shard will form a block, but even PBFT (tendermint style) solution would work in situation when you don't have to worry about membership of validator set.

Offtopic. DLT is basically a marketing fraud. Both "permissioned" and "permissionless" DLT are packed into one term. Problem is - they are vastly different. Permissioned DLT is not interesting at all from technical and social point of view. We knew how to do them for a long long time. Openness, permissionless is the key innovation introduced with Bitcoin. "Permissioned blockchains" are just repackaged tech with lot of marketing sauce.

Plasma is not for payments. It is a counterpart of Lightning Network, but for code. With LN you can do a lot of extremely cheap payments. With Plasma you can do the same for arbitrarily complicated code. Idea is - take some tokens to domain specific plasma chain, do your interaction with possibly byzantine actors, settle on parent chain when you are done.

Today even timestamping is expensive in decentralized world. Plasma actually allows you to do that cheaply.

You can do Proof of Authority instead of Proof of Work to cut down costs.

The real reason behind techniques such as PoW instead of just Distributed Byzantine Fault Tolerance algorithms is scaling in terms of number of validators. Most of DBFTs (afaik Algorand is the only exception) don't really scale. Proof of Authority behaves similarly to PoW, since it also does not have that problem.

Go with DBFT unless you want to have huge number of validators.

Those will be addressed with Lighting Network [0]. ATM there are ~4 implementations of the concept. None is complete/mature yet.

[0] http://lightning.network/

Because encryption without authentication is prone to MITM attacks. WebTRC does not have auth layer.

And BTW if you do the math a bicyclist (in the US, eating a typical US diet) emits more CO2 per mile than a small car. Assumptions: The bicyclist is riding in addition to any exercise, the riding is not exercise, and the bicyclist eats normal food. A bicyclist who prefers organic, or local, would definitely emit more (both of those emit more CO2 in the growing than regular food).

This result is useless since it makes impression that those miles are interchangeable while they are not. No bicyclist will make same amount of miles per unit of time as car driver. Bicyclist will make other choices: living closer to the job, working remotely, etc.

Just FYI. Brujo is close to being expert in Erlang. This post is a more of a "warning for juniors" than "damn, today I've discovered something new".

And there is nothing really WAT about it. Just part of rather simple Erlang language grammar.

I think that not using Erlang in this particular case was a mistake. Erlang is running some of the largest chats out there, including League of Legends and WhatsApp. They would have avoided all the hassle of GC pauses, since Erlang has per-process GC collection. And scaling single OS process to their number of connections was done for Erlang machines years ago.