You definitely need to trust the federation that controls peg-outs [1]. From the whitepaper [2]:

> As a sidechain, Liquid supports transfers of bitcoins into and out of the system by means
of a cryptographic peg. Bitcoin pegged into Liquid is referred to as Liquid Bitcoin or LBTC. The forward progress of the Liquid ledger and custody of the underlying bitcoin are
controlled by a federation, and remain secure as long as over 2/3 of its members are honest.

> This option requires no changes to Bitcoin, since the peg is enforced by means of ordinary
multisignature transactions. It does require a consortium to exist, and for participants of
the system to trust that at least 2/3 of the federation is acting honestly.

[1] https://help.blockstream.com/hc/en-us/articles/900001551783-What-is-a-Liquid-peg-out-

[2] https://blockstream.com/assets/downloads/pdf/liquid-whitepaper.pdf

The devtax was originally advertised as 10% of total supply, by 20% tax on first the 4 years which generates half of total supply.

But before those 4 years were up, they voted to extend it another 4 years, and now with the planned switch to PoS it becomes effectively 20% of total supply. So much for immutable monetary policy...

No, the attacker couldn't because there's no exchange or trading platform that supports Sapling -> Sapling transactions. In fact most exchanges only allow trading the transparent pool.

There's only a risk of unlimited ZEC *within the old Sprout/Sapling pools*. There is no risk of that unlimited ZEC getting out to either the transparent or the Orchard pool due to turnstiles.

So the only risk is to people who keep ZEC in the old shielded pools in case the turnstile prevents them from getting their funds out due to someone else having inflated funds moved out.


Disagree. The upgrade clearly means something with the turnstile protection and with the new address format defaulting payments to the Orchard pool.

As of their NU5 upgrade on May 31, Zcash no longer relies on a trusted setup [1] [2].

[1] https://www.coindesk.com/tech/2022/05/31/zcashs-nu5-upgrade-goes-live-boosting-privacy-and-removing-trusted-setups/
[2] https://zips.z.cash/zip-0224

Nothing unusual there.
Todd went on a long road trip [1], staying at an unpredictable motel, buying a disposable computer and thoroughly destroying it afterwards, generally making lots of expenses for which Zcash reimbursed him.
Snowden probably chose to make negligible expenses and declined to be paid.


If you want to talk about shady history, look at Monero's Cryptonote origins with the Bytecoin scam [2] and the purposely obfuscated inefficient miner software [3]...

[1] https://www.coindesk.com/markets/2016/11/14/zcash-and-the-art-of-security-theater/

[2] https://bitcointalk.org/index.php?topic=4508322.0

[3] https://da-data.blogspot.com/2014/08/minting-money-with-monero-and-cpu.html

Of course it's considered possible in theory.


There's no need to reorg the chain. They just build a block with a segwit stealing tx, which everyone else ignores
(as it breaks the segwit softfork rules), but that they keep building on. Since they are assumed to have a hashpower majority, their chain will likely stay ahead of the segwit-faithful branch that other miners build on.

No it wouldn't, because exchanges and other non-mining entities would ignore this longest branch which breaks their rules. All that would happen is that blocks come in more than twice as slow until the next difficulty adjustment kicks in.


They would be left with nothing, since everyone else sees their coinbases as invalid.
In short, it's not just up to the miners.

Zcash currently allows all 4 directions between transparent t addresses and shielded z addresses: t2t, t2z, z2t, and z2z. I'm not sure how these qualifiers work if you have different types of inputs, or different types of outputs in one tx.
A first step to phasing out transparent addresses is to disable z2t, so once shielded you stay shielded. A second step is to disable t2t, so you cannot create new transparent outputs. I don't think you want to take either step in Bitcoin.


IMO a coin that values full auditability should keep private amounts optional, although one could argue that with ElGamal commitments, at least unconditional soundness is preserved.

I wouldn't say "Of course" when you didn't consider it in the first place...

Obviously, because privacy is optional in Zcash.
Only a small minority (0.8M of 15M ZEC) of coins lives in shielded pools, and only a small fraction of transactions is z2z.

It seems most Zcash users are not interested in its privacy features, but hope to profit from other people's interest in its privacy features.

Not every bitcoin owner needs to have an entire block reward. You could split up the 7.5B people in the world into
750K groups of 10K. If each group won one of the 750K blocks so far, then each group could split the reward of say, 25 BTC = 2500M satoshi into 250K satoshi for each member.

Remember there are plenty satoshi to go around...

Litecoin begs to differ.

It only made some relatively meaningless tweaks to Bitcoin (or to the now forgotten Tenebrix to be precise), and its much-touted ASIC-resistance proved to be extremely short-lived (its PoW now just takes a needlessly long time to verify), yet it went on to be rather successful in terms of marketcap.

Doge itself launched as a Litecoin clone with a few more meaningless tweaks.
It did make a very meaningful change later though, when it introduced Tail Emission.

Cuckatoo32 is designed to be ASIC friendly, and there are in fact ASICs for it.
But where SHA256 can be seen as proof-of-logic-circuit, C32 is proof-of-SRAM.
You need 512MB of SRAM to find solutions most efficiently.

It's true that the performance gap with GPUs is much smaller than for SHA256,
and current ASICs don't have enough SRAM to achieve full efficiency, but for
future ASICs there will be at least an order of magnitude gap.


The actual Cuckatoo32 verifiying logic should be easy to integrate into Bitcoin Core. The majority of effort needed will instead be for enlarging the header with a new field for the 42 cycle indices of size 42*32 bits = 168 bytes. I'd advise you to first get your blockchain working with this larger header, where you just ignore the contents of the new field. Let me know when you have that working.

You can pre-sign incoming transactions of predetermined denominations from a hot wallet to a cold wallet,
and keep them stored in the hot wallet to be used at any later time. So it can be made to work with a few limitations.

Strange to hear you denounce Lightning just like that...

If Bitcoin is to achieve any sort of mainstream adoption, and actual use as a currency, then most users will eventually be far more familiar with the interactive nature of L2 transactions than the non-interactive nature of L1.

Btw, another advantage I haven't mentioned is that multisig greatly reduces worries about mistyping addresses or sending to the wrong address, since the receiver must actually prove being able to spend received funds before being able to receive them. That gives much more peace of mind and mostly avoids the need for an extra "test" transaction of negligible value before a big value transaction.

There are coins significantly simpler than Bitcoin, e.g. https://bitcointalk.org/index.php?topic=5309951.0
Bitcoin's script is a huge source of complexity which runs counter to having a focused feature set.

So I can make you look shady by claiming I paid you and releasing my fake side and by definition you couldn't release yours?

It seems you want to transact with people whom you trust and don't trust at the same time.
You trust them to provide the goods/services you pay for, but
you don't trust them not to disclose tx info without your consent.


Any mempool observer can reconstruct (nearly all of) the transaction graph.
But chain analysis on this graph is hard without any visible amounts or addresses.
It's even harder if most transactions are payjoins (i.e. receiver also provides an input), so that you cannot distinguish between payer and payee. Thanks to the interactivity required by MW, payjoins are just as easy as non-payjoins.

It's also not that useful, as payments can trivially be denied by a fraudulent receiver, with no recourse for the buyer.

Payment proofs are a critical component to a functioning digital payment economy.

Mimblewimble supports payment proofs. For a payment from Alice to Bob, this is a statement signed by Bob's public key (associated with his wallet) that appearance of certain data on-chain (sufficiently confirmed), proves that he was paid by Alice. The statement can include amount, time, and purpose of payment.
BUT Bob's agreement is not needed to release this info. In fact, payment proofs are useful in cases where Bob promises to provide some goods or service in exchange for Alice's payment, but then fails to do so. Now Alice can submit the payment proof to some 3rd party (e.g. a court) as evidence for Bob's fraud.


I think amount and address privacy is best built into the base consensus layer, as these improve scalability as well in case of MW.
But hiding input-output links (obfuscating the tx graph) on the base layer comes at a large cost in either scalability or (in case of recursive snarks/starks) in trustworthiness, so perhaps that is better added on as separate service  (such as the Mimblewimble CoinSwap protocol).

That makes no sense. Pure MW has no addresses.

The only thing you can see in the mempool that you cannot see in blocks are the original
transaction boundaries (except for txs that got aggregated in the Dandelion phase, but that is rare).

Mimblewimble Coinswap for Grin is still in development.