"Nor do we use any cryptographic verification inside the core

of the transaction processor to achieve auditability"

don't require intermediaries to aggregate transaction: *why*? I suppose they did "forsee more complexity" in this choice. They should.

privacy: "just don't retain it bro" uh...

it's quite intriguing that the first justification they give in using a utxo system is that it's compatible with privacy extensions. they don't actually need to, and in fact the requirements may be the opposite.

UHS: this is similar to the Scripthash that fulcrum/electrumx uses (the exact replica is "An alternative transaction format could compute the has with only the public key and value...). The privacy claims are a bit dubious since the main source of attacks are actors who have access to the transactions themselves anyway.

UHS: note that the storage benefits isn't that big for normal transfers (the outputs of p2pkh are barely bigger than hashes), and are only manifest in larger encumbrances. we don't know how much need there is for that in exchange for one whole additional layer of complexity; this is quite core-ish in terms of marginal privacy and scalability "improvements". there is generally very limited advantage over p2pkh.

UHS: if it wasn't clear from reading: all of the processing-layer separation benefits also apply to plain ol' UTXO in the exact same way.

Guard against inflation attacks: This isn't actually a hard requirement, and highlights the superiority of an account-based system (which can be more easily tied to identities, where authorities can execute reconciliation on)

Requirement to post transaction to recipient: This is a large UX downgrade that is done perhaps to cater to the unnecessary UHS abstraction. Unlike actual privacy coins i.e. XMR this is still vulnerable to attackers that have access to transactions.

This whole "transaction processors don't store outputs therefore privacy is preserved" gimmick really sounds like a ploy to make it look at least different from bitcoin to justify their pay tbh

push vs. pull payments: did these guys not learn about covenants? i suppose this is another problem with UHS abstraction, the recipient can't just search for encumbrances payable to himself. this whole abstraction layer is nuts.

"the atomizer": nothing really new here, this is how all leader-based crypto operates. in bitcoin the atomizer is delegated to PoW.

note that this might be the extent of how these guys imagine bitcoin(cash) can ever be, which ain't half bad. that's about 2 transactions per person per day for the planet.

"two phase": the fault tolerance requirements seem to assume *all* components (shards and coordinators) need to stay correct instead of just the comparatively lightweight atomizer. this seems quite a bit more fragile than the atomizer design. Note that shards here must commit to sections of the UHS one-to-one, "is handled by one shard cluster, at most".

also note that this is how most people imagine sharding will work. contrary to their claims, you *can* audit ordering; it'll just have to be done on each shard for their portion of the UHS/UTXO.

when discussing atomizer, "it also means that transactions can fail for transitory reasons": bro you can just confirm one of the conflicting tx instead of failing all of them, it's not that hard.

Note that while I blasted the "two phase" design, it's not unreasonable to imagine some far future design where sharding is employed to scale bitcoin; it'll be very tricky to redesign how PoW can be applied to individual shards though.

It seems like all the components are assumed honest, which is jarring even for a PoA CBDC. Are they relying on post-hoc audits and punishments if sentinels, shards, coordinators etc. become dishonest?

💎