Quote from: AB de Royse777 on Today at 01:27:47 PM

Quote from: NeoMoney on Today at 12:35:13 PM

Here’s my core constraint:

When the next person receives BTC (either through trade or withdrawal), it must be the exact same BTC originally deposited by John — not from James or a general pool.

So when Harry withdraws, I want to ensure the withdrawal is signed using John’s wallet key, since that UTXO technically still resides in John’s wallet (now owned by Harry).

Isn't it too complicated?
I sold BTC to you and now you are waiting my approval to sell/withdraw the BTC. The relation between me and you should be completed once I release the BTC and it goes to your account (internal balance). With that balance whatever you do, why would you need my involvement.

You will give the address to your users but the private key is held by you?

Yes, you're right — I’ve been overcomplicating it by trying to preserve UTXO provenance across trades. That would create unnecessary friction after the trade is settled.

Small note: John himself doesn't need to sign anything after it's transferred internally outside of his balance since we have his private key.

I’m now leaning toward a Bisq-style architecture, where users hold their own keys and trades occur through escrow-based multisig. To scale that inside a fast, low-fee system, I’m thinking of using a Bitcoin-based ZK rollup-style L2, where:

Users retain control of private keys

Trades are coordinated off-chain through a state ledger

Disputes are settled via multi-sig or staked arbitrators

The full state is anchored to Bitcoin periodically

This keeps everything auditable, custody-transparent, and removes the need for pooling or origin-tracing of funds between users.