Alfred Hodler [ARCHIVE] on Nostr: 📅 Original date posted:2022-07-01 📝 Original message:Hi Clark, Thanks for your ...
📅 Original date posted:2022-07-01
📝 Original message:Hi Clark,
Thanks for your input.
I agree with your proposal to use bech32 instead of base58. It looks sound to me and as you said, the standard would benefit from more compact QR codes. The `pay1` prefix is fairly recognizable.
> I don't see how this would work, and others have pointed out that the
> cost of block space is itself an anti-spam measure.
I agree.
> A third-party service could offer to publish OP_RETURN notification
> payloads in the blockchain for a fee, paid over Lightning Network.
> This completely de-links Alice's notification from her wallet, while
> accepting the less-known privacy implications of a Lightning payment.
> The service would remain ignorant of Bob's identity in any event. Such
> a service would also be incentivized to charge market rates for the
> potential privacy boost and for block space.
The manner of publishing or outsourcing notifications cannot be enforced by the standard but we can add this as a recommendation. We can also release such a service in tandem with the BIP in order to encourage its use. The fact that the service would use its own coins would be beneficial to notifiers since they wouldn't have to engage in coin control on their end.
I'm not too familiar with the innerworkings of Lightning, but it is my understanding that a message can be embedded in each payment. The message in this case can be the OP_RETURN payload. That way both the payment and the notification payload are sent out in one go. Please correct me if I'm wrong.
The downside is that this isn't as censorship resistant as direct notifications but that's probably not going to be a big problem in reality. If these services ever go down, users should still be able to notify from their own wallets.
> Alternatively, the service publishes the block height along with the
> notification data contained within that block. Light clients could
> download relevant blocks over the p2p network and perform full
> validation.
This sounds better than requesting transaction data, both from the standpoint of simplicity and privacy. The danger is that the service drops notifications, either on purpose or by accident, eventually causing clients to miss notifications. Two possible solutions: a) the service publishes Merkle Trees b) each client subscribes to more than one service.
Alfred
📝 Original message:Hi Clark,
Thanks for your input.
I agree with your proposal to use bech32 instead of base58. It looks sound to me and as you said, the standard would benefit from more compact QR codes. The `pay1` prefix is fairly recognizable.
> I don't see how this would work, and others have pointed out that the
> cost of block space is itself an anti-spam measure.
I agree.
> A third-party service could offer to publish OP_RETURN notification
> payloads in the blockchain for a fee, paid over Lightning Network.
> This completely de-links Alice's notification from her wallet, while
> accepting the less-known privacy implications of a Lightning payment.
> The service would remain ignorant of Bob's identity in any event. Such
> a service would also be incentivized to charge market rates for the
> potential privacy boost and for block space.
The manner of publishing or outsourcing notifications cannot be enforced by the standard but we can add this as a recommendation. We can also release such a service in tandem with the BIP in order to encourage its use. The fact that the service would use its own coins would be beneficial to notifiers since they wouldn't have to engage in coin control on their end.
I'm not too familiar with the innerworkings of Lightning, but it is my understanding that a message can be embedded in each payment. The message in this case can be the OP_RETURN payload. That way both the payment and the notification payload are sent out in one go. Please correct me if I'm wrong.
The downside is that this isn't as censorship resistant as direct notifications but that's probably not going to be a big problem in reality. If these services ever go down, users should still be able to notify from their own wallets.
> Alternatively, the service publishes the block height along with the
> notification data contained within that block. Light clients could
> download relevant blocks over the p2p network and perform full
> validation.
This sounds better than requesting transaction data, both from the standpoint of simplicity and privacy. The danger is that the service drops notifications, either on purpose or by accident, eventually causing clients to miss notifications. Two possible solutions: a) the service publishes Merkle Trees b) each client subscribes to more than one service.
Alfred