Quote from: tiagocs on August 11, 2020, 07:21:18 PM

@RHavar may I see what you have tried? I'm interested in this subject. My name for it was "dynamic batching".

I'm not sure it's very useful, as not only did I not get it working -- I'm not sure how to do so. But I think the "project scope" was pretty interesting.

Basically the idea was to build a "commercial wallet" that sits behind a trusted bitcoin node (avoid a lot of validation nonsense and risks etc.). And then provided a really robust API for sending/receiving payments. And I made a very strong distinction between a "payment" and a bitcoin transaction. As in a payment might be: "I want to pay X with N BTC with Z priority" and you could track that payment and see which "bitcoin transactions" it gets reified into (which might keep changing until it eventually confirms).

The other feature I was trying to build which I'm a huge fan of, is something I call "utxo-giftcards". Where a "utxo-giftcard" is basically a (txid:vout:privatekey). So when you import someone elses utxo-giftcard the wallet knows that it's "untrusted" and that because a 3rd party also has the private key it could be double-spent easily. And a "utxo-giftcard" is considered "redeemed" when the wallet itself spends it (as opposed to a 3rd party does). And when adding a "utxo-giftcard" you could specify the "redeem priority".

The reason I'm such a huge fan of the idea of "utxo-giftcards" is that it's pretty phenomenally space-efficient (as you can give someone money without even making a transaction) and a death-blow t entire classes of bitcoin analysis attacks. (Of course there are drawbacks in transferring a private-key, but I feel those are pretty obvious and understood enough that it's easy to use what is most suitable)