NIP-43: Bitcoin-Funded Public Keys to Prevent Spam

[brunneis]

This NIP specifies that Nostr relays can implement a filter to check the balance of a bitcoin address derived from a Nostr public key. The filter will be triggered whenever an event is received from a client. If the current balance of the bitcoin address is less than the minimum configured by the relay, the message will be rejected.

PoC implemented at: https://github.com/labteral/nostrd

[ghost]

Interesting although it's risky to use nostr keys for deriving bitcoin address at this moment. Many web clients used for social networking are vulnerable and users might lose funds if their nostr private keys are stolen.

[nullpraxia]

could this also act as a kind of sentinel wallet, revealing that your private key has been compromised if the funds are taken?

[brunneis]

Interesting although it's risky to use nostr keys for deriving bitcoin address at this moment. Many web clients used for social networking are vulnerable and users might lose funds if their nostr private keys are stolen.

Thanks! The current risk has to be handled sooner or later with hardware devices IMO. I think the identity theft risk is much worse than losing the bitcoin deposit (presumably not a lot of money).

[brunneis]

could this also act as a kind of sentinel wallet, revealing that your private key has been compromised if the funds are taken?

If a private key becomes public, it is likely that someone will move the funds associated with that key. However, if the private key is compromised without being made public, I foresee two main scenarios:

1. If the account is relevant, the attacker may use the compromised key to impersonate the victim for a while, and might not immediately move the funds.
2. If the account is not relevant, it will be likely that the funds will be immediately moved once the private key has been compromised (useful sentinel for the owner).

Therefore, this property is most useful when the value of the locked funds is greater than the potential benefit of impersonating the victim's identity for a short period of time (before trust in the account is lost due to the attacker's actions).

[nullpraxia]

it also gives the original key holder an account kill switch

[brunneis]

this shouldn't be a NIP in my opinion

• relay spam prevention measures should be implemented through protocols where any medium can be used, such as CAPTCHAs, LN, etc
• it is unsafe to treat Nostr keys as addresses

I don't agree.

1. This is not the NIP to deal with spam, but one of many, potentially. It defines a non-exclusive (and optional) way to try to deal with it with a specific technique. It is up to the community to apply it or not in their relays. Approved or not. As I said, in any case, I am not trying to force this way or making it "the way" to effectively control spam. In fact, it is insufficient alone.
2. Why is it unsafe to use Nostr keys as addresses? Those addresses are not intended to keep large balances. If it is unsafe because of the current poor management of private keys that will be solved, eventually. Probably with hardware devices. In any case, your Nostr keys should be more valuable than the small bitcoin amount with which the account was funded, as it represents your identity and there is a risk of impersonation. This is especially important in the case of anonymous users where the public key could be the only link to their reputation.

[nullpraxia]

@brunneis this would seem to make spamming from many public keys expensive.

couldn't bad actors move funds around between addresses to evade filtering though?

i remain intrigued by the potential applications of associating a nostr public key with a funded bitcoin wallet, however the game theory of this working as spam protection is unclear to me.

[brunneis]

@brunneis this would seem to make spamming from many public keys expensive.

couldn't bad actors move funds around between addresses to evade filtering though?

i remain intrigued by the potential applications of associating a nostr public key with a funded bitcoin wallet, however the game theory of this working as spam protection is unclear to me.

First of all, there are costs associated with funding an account and moving the funds around (tx fees). If the funds are repeatedly moving, the number of iterations is limited for a fixed amount of bitcoin. In any case, the main point for this to work is that the funds must remain untouched while the account is "alive".

I identify two main scenarios:

1. The deposit acts as a killswitch. I would analyze funding UTXOs instead of balance here. If the funds are moved, the account is considered untrustworthy or dead. In this scenario, the funds cannot be moved around without blowing up the previous accounts.
2. The deposit does not act as a killswitch. If the balance goes down, no new events will be accepted while the account remains unfunded. This means that the bad actor cannot use several accounts at the same time when reusing funds. In addition, an account could be considered funded with 1 confirmation, for instance. This means an average 10-minute wait for the bad actor, limiting their activity even more. It could even cause the purge of the stored messages on the relay side. Combining this with a rate limit per account also implies a time cost to restore old events since they must be resent.

[Werpers]

Have you considered burning the bitcoin instead of leaving them spendable? This would make the pubkey inherently valuable, enhancing the spam deterrence.

Another thought is that perhaps this could be more general than just for relays. If it just defined a way to calculate "the value" of a pubkey, both relays and clients could use this value to make decisions on what to do with events from a given pubkey.

[Semisol]

i'm not against the idea of locking up bitcoin to public keys. i'm against having them easily movable and require the funds be in the same key as the nostr address

simple fix:

• use a taproot address with there being a custom public key or spend script (pubkey + CLTV for example to make a fidelity bond)
• the address also has a leaf that commits to the nostr public key

you could require the entire merkle tree for the address is revealed too so one address commits to only one public key

[Aspie96]

How would this actually reduce spam?

Advertisers of all kinds are perfectly willing to spend a bit of money to advertise and spam. The vast majority of regular users of social media, on the other hand, don't pay anything.

This just proves that the author of event owns some money, not that the event isn't spam.

[LouisLibre]

This could be implemented at relay level, no need for a NIP.

It's like a proof-of-bitcoiner membership scheme.

• "Only members with at least 100,000 can enter this relay"
• "Only wholecoiners can enter this relay"

Heck, even shitcoiners can use this as proof-of-membership.

• "Must have an NFT in the eth wallet derived from the nsec"

[staab]

Closing due to inactivity