From your text "Layer A: anchoring evidence on the chain
In verifiable-accounting, the first layer (it corresponds to the invention in patent WO 2022/100946 A1) proves that a target data item is present in a BSV block, using a Merkle proof whose root is the block header’s own merkleroot field. Every Bitcoin block header commits to a Merkle root of all the transactions in that block; verification rehashes from your leaf up to that header root, and the header itself sits in the validated chain of headers secured by proof-of-work. So the chain of trust runs: your record → its hash → the path → the block header’s Merkle root → the header chain → proof-of-work. Nothing in that chain requires you to trust me, the auditor, or any server. It terminates in the most expensively secured data structure in existence."
Very interesting! I hadn't thought of it like that.
Noted: "A technical choice worth naming: pushdata, never OP_RETURN
The Merkle root is carried inside a BSV transaction as pushdata in the script — data pushed onto the stack as part of a real, spendable script — rather than in an OP_RETURN output. OP_RETURN marks an output as provably unspendable, a dead-end for storing data. Carrying the commitment as pushdata in a live script keeps the evidence inside the spendable, chainable transaction graph, which is what lets the spend-linking work. It is a small decision with large consequences, and it is the kind of decision that only matters if you are actually building the thing."
Is it technically possible to create a TEE (trust execution environment) on the user's own device, like a code execution "black box"?
yes, Samsung, IPhone and many systems have a TEE built in.
From your text "Layer A: anchoring evidence on the chain
In verifiable-accounting, the first layer (it corresponds to the invention in patent WO 2022/100946 A1) proves that a target data item is present in a BSV block, using a Merkle proof whose root is the block header’s own merkleroot field. Every Bitcoin block header commits to a Merkle root of all the transactions in that block; verification rehashes from your leaf up to that header root, and the header itself sits in the validated chain of headers secured by proof-of-work. So the chain of trust runs: your record → its hash → the path → the block header’s Merkle root → the header chain → proof-of-work. Nothing in that chain requires you to trust me, the auditor, or any server. It terminates in the most expensively secured data structure in existence."
Very interesting! I hadn't thought of it like that.
Noted: "A technical choice worth naming: pushdata, never OP_RETURN
The Merkle root is carried inside a BSV transaction as pushdata in the script — data pushed onto the stack as part of a real, spendable script — rather than in an OP_RETURN output. OP_RETURN marks an output as provably unspendable, a dead-end for storing data. Carrying the commitment as pushdata in a live script keeps the evidence inside the spendable, chainable transaction graph, which is what lets the spend-linking work. It is a small decision with large consequences, and it is the kind of decision that only matters if you are actually building the thing."