Hello, i am looking into implementing cashu nip-60 wallets as a receiving attachment for stackernews, but i've hit a blocker that would require this feature.
Stackernews needs all the attachments to act as lightning wallets, so i was going to create the quotes on the server and present their lightning invoices to the sending side, after the payment then the server was going to mint tokens with a p2pk spending condition that targets the receiver and finally nutzap the tokens to the receiver using nip-61.
The problem is that nothing stops the server from changing its mind and mint tokens without the p2pk spending condition after the quote invoice is paid, and as far as i understand, this little thing is the line that if crossed makes stackernews a money transmitting service under the current laws (ie. it can pretend to be honest but then steal during the money transmission phase).
I think this could be avoidable if there was a way to create a quote that has a contract that says the minted tokens must have a specific p2pk spending condition, the quote should also have a signed message from the mint that attests the invoice is really for a quote that must have the declared p2pk condition.
With this the code can verify the quote is valid on the sending client, and if sn decides to cheat, once it reveals the proofs the mint can just see the p2pk contract is not met and reject the unlocking.
Hello, i am looking into implementing cashu nip-60 wallets as a receiving attachment for stackernews, but i've hit a blocker that would require this feature.
Stackernews needs all the attachments to act as lightning wallets, so i was going to create the quotes on the server and present their lightning invoices to the sending side, after the payment then the server was going to mint tokens with a p2pk spending condition that targets the receiver and finally nutzap the tokens to the receiver using nip-61. The problem is that nothing stops the server from changing its mind and mint tokens without the p2pk spending condition after the quote invoice is paid, and as far as i understand, this little thing is the line that if crossed makes stackernews a money transmitting service under the current laws (ie. it can pretend to be honest but then steal during the money transmission phase).
I think this could be avoidable if there was a way to create a quote that has a contract that says the minted tokens must have a specific p2pk spending condition, the quote should also have a signed message from the mint that attests the invoice is really for a quote that must have the declared p2pk condition. With this the code can verify the quote is valid on the sending client, and if sn decides to cheat, once it reveals the proofs the mint can just see the p2pk contract is not met and reject the unlocking.