I'm tagging [Problem: no way for the relay to see which pubkeys have paid] with the Rocket: nostrocket

I'm tagging [Problem: no way for the relay to see which pubkeys have paid] with the Rocket: nostrocket

I'm claiming [Problem: no way for the relay to see which pubkeys have paid] on the nostrocket problem tracker so that I can work on it and other people don't duplicate my efforts.

I previously claimed [Problem: no way for the relay to see which pubkeys have paid] on the nostrocket problem tracker, but I'm not abandoning it and freeing it up for other people to claim.

Problem: can't derive the next payment address from current state of nostrocket

There's currently no implementation of the nostrocket payment round-robin algorithm.

This is core to nostrocket being non-custodial.

Using lightning prisms is one option, but there are currently no best practices to make this non-custodial, it currently relies on lightning nodes to do the actual work of splitting the payments and forwarding the sats to multiple wallets. This is not an option for Nostrocket because it must remain non-custodial and therefor cannot recieve payments.

Payments for products/services created through Nostrocket must go directly to the meritholders of the rocket recieving the payment.

The Nostrocket payment round-robin is an algorithm to determine the next-payment-address from the current set of merit-holders such that incoming payments are eventually-congruent with the proportion of merits held by pubkeys within a rocket.

This algorithm is defined in detail by the Nostrocket Unprotocol but it is not yet implemented.

Problem: can't pay for specific products/services

We can derive the next payment address from the current nostrocket state, but we can't actually store the result of payments anywhere.

Soluton:

Allow rocket maintainers to add predefined amounts (in sats) for incoming payments. This way we can create a new invoice for the next payment address for each payment amount and store this invoice in state.

When a user makes a payment, the client will publish an event that contains the preimage, proving that the payment has been made. When the state machine sees this it adds the payment to state, mapped to the pubkey of the user who paid.

This will introduce a vulnerability whereby someone could "frontrun" the preimage, but whatever it's good enough for now.

I'm closing [Problem: no way for the relay to see which pubkeys have paid] on the nostrocket problem tracker, it's been resolved or become obsolete.