Peter Todd

This analysis is correct and it looks like SingleFile doesn't provide protection from this class of attack.

However, there are solutions that can protect against this type of attack. The attack you describe above is similar to what is known as a "double-spend" attack. Using a digital signature you can prove that a particular key (and therefore user) signed a particular transaction, but cryptography alone cannot prove that there was not another competing transaction that spends the same funds. Prior to Bitcoin, digital currencies required a central database to prevent these double-spends. With Bitcoin and subsequent cryptocurrencies this attack is prevented via a distributed database with a consensus algorithm.

Peter Todd (and others) have generalized prevention of double-spends to the idea of a "single-use seal" which can be implemented using the Bitcoin blockchain as an implementing decentralized service. [1] The idea is that there is some kind of formal protocol used (a higher layer in the protocol stack) and in the example above, the political prognosticator ties the hash of their single prediction of the winner of the presidential election to a particular Bitcoin UTXO (unspent transaction output) which serves a "single-use seal". The combination of the higher-layer messaging protocol and the "lock" to a single commitment tied to the UTXO limits the prognosticator to a single prediction. They don't have to reveal their prediction at the time it is made, but they do have…

I think you have to be more precise when making claims of this sort; in this case "establishing a global clock" is not very precisely defined. Suppose we have an oracle that implements this protocol: it publishes a new public key every hour, and at any time someone can present it a blob of data which it will sign with the private key corresponding to the current hour's public key. Furthermore, you can query it for the set of all blobs it has signed with a given public key. It is obvious that one can implement a distributed ledger with the only security assumption (for each user) being "I trust this oracle" and "I can determine the current time". OTOH, suppose we have a weaker oracle which implements this protocol: every hour it publishes a new blob of data. Then it is probably not possible to implement a distributed ledger using only the weaker oracle.

It is well-known that pure cryptography is strictly weaker than cryptography + economic assumptions or cryptography + subjectivity assumptions, due to some inherent information-theoretic asymmetries. For instance, pure cryptography allows us to prove that the owner of the secret key of a given public key has signed a message, but it cannot let us prove that the owner of a secret key has NOT publicly signed a message. A way to do this by relying on economic and non-coordination assumptions is to offer a public bounty (ie I will pay some USD) to anyone who can provide the signature and then to wait some time to see if anyone…

Both of Hearn's articles contain a number of factually incorrect points. For example, his article on forks states that:

> In a soft fork, a protocol change is carefully constructed to essentially trick old nodes into believing that something is valid when it actually might not be.

The soft-fork protocols used for upgrades are specifically designed to ensure nodes are not tricked into believing something is valid when it might actually not be, as there is a well-defined mechanism - the block header nVersion field - that both co-ordinates soft forks and ensures that nodes that are unaware of the specifics of a given soft-fork know that there are new rules in effect. This is why at present, Bitcoin Core nodes/wallets loudly warn you that unknown rules may be in effect that your node does not understand, because the BIP91 soft-fork just activated that Bitcoin Core does not recognize. (BIP91 is a temporary hack to activate segwit at 80% rather than 95% threshold; in a few weeks it'll no longer be relevant to consensus)

Hearn is misleadingly confusing the adversarial case where a majority of miners may try to change the rules without consent of the community in an undetectable fashion, but that's simply a 51% attack. At present, preventing such attacks is an open research question; conflating the 51% attacks and soft-fork upgrades is very misleading.

In Hearns "resolution of the bitcoin experiment" Hearn states that:

> Bitcoin Core has a brilliant solution to this…

Not the least bit surprising to hear this considering his overt advertising on Twitter for Zcash.

https://twitter.com/Snowden/status/1462532222368591884

Peter Todd (Bitcoin developer) was another participant in the Zcash creation ceremony. He wrote a post about it and cast doubts about the process.

https://petertodd.org/2016/cypherpunk-desert-bus-zcash-trusted-setup-ceremony

A “scientist” on the Zcash team, Matthew Green, spoke of backdooring Zcash once upon a time.

https://twitter.com/notgrubles/status/1011830929004875777

I’m not saying there’s a conspiracy at play here, but more so putting a spotlight on Snowden’s untrustworthiness.

https://twitter.com/Snowden/status/913557610858778625

Here is Snowden (un)subtly favoring Zcash over Monero, another privacy coin. Not suspicious at all given his secret ties and financial incentive to Zcash and its curious, sketchy history.

This isn’t to mention the “Founders Reward” that cut 10-20% of mined coins to the creator’s wallets (“ The remaining 20% of the reward was split among various parties including 9.85% to ECC founders, 2.2% to the Zcash Foundation, 5.75% to ECC itself and 2.2% to ECC employee compensation.”)

https://www.coindesk.com/tech/2020/11/18/zcash-undergoes-first-halving-as-major-upgrade-drops-founders-reward/

Or the fact that Zcash is opt-in privacy, meaning 99% of transactions are transparent and 1% of users opt for privacy (not suspicious at all for those users, wouldn’t one think?)

I mentioned that fork because you implied that a 75% hard fork would be effectively riskless. There are all kinds of things that can go wrong, and not wanting a hard fork unless there are no other options is prudent.

RBF helped the existing problem of transactions never going through. A fee market will need to develop eventually anyway (as nullc has said, there's an unlimited amount of data people would like to store for free), and allowing fee changes for transactions where zero conf acceptance is not required is a step towards making transactions easier in a fee market.

Claiming that RBF is not careful is something I can't agree with. If wallet designers disregard a feature of Bitcoin that's been there from the beginning, and users accept zero confs without doing basic security checks, protecting them isn't more important than providing features to everyone else. First seen was never advertised as secure, and if you're too lazy to check for that flag I don't really care. Considering that double spends were still very possible previously, and the detection is one line of code, I'm not particularly worried. https://petertodd.org/2016/are-wallets-ready-for-rbf points out that none of the top wallets would detect a regular double-spend even without RBF.

The trusted setup is not as bad as those two words make it sound without any context:

1. All people present in the trusted setup would have to be colluding or be compromised to cause an issue.

2. Some of these people have reason to make the currency succeed, because they own large amounts of zcash.

3. Some show the lengths they went to to prevent compromise: https://petertodd.org/2016/cypherpunk-desert-bus-zcash-trusted-setup-ceremony

One of my own opinions on collusion:

If collusion was suggested by one or more of the people present in the setup it would be quite likely that another one would have come out and said something about it. This would have made zcash and the person itself very untrustworthy. This makes it likely that it wasn't worth the risk to the person thinking of collusion in the first place.