Went ahead and added a Bitcoin and a Bolt12 address to my profile. Waiting for some more elegant concept, but I want to send a signal.
#MehrPaymentRailsWagen
Discussion
Has anyone used Bolt12, already?
i use it
I have. I once put it on my profile, but Incouldn't copy and paste so I put it on my ghost blog and made it copy-able with Markdown syntax.
`lno1zrxq8pjw7qjlm68mtp7e3yvxee4y5xrgjhhyf2fxhlphpckrvevh50u0qv6saa5j2s7tl25jnx94v6gsrj7y4wrtlhny4339rrsaahp0tevxcqszexel6ydr0addnfjydecv06qwfrwx2rnygnmk9hzlgngzv97cg8lsqvc5pm7rr87xgsjsx9l0cky5cwkg47wletgvly3jszgkqhfuxna9dqc6qawzmz7upnu8elkaryh6wvkcmw4eqgwwme0k3z0628mvdc6mgtjcct2hs7fld2rc770szp4v7gnquz47jqqsrm3j3fx0d76z2q7ayu4yw72fwv`
try putting your offer in twelve.cash so it is ln address readable, i coukd try zapping you from my core lightning node. just for funsies see if it works
would be cool too if CoinOS can zap a twelve.cash address in a profile using nwc 🤔
Bought the vanity version and added it to the profile.
laeserin@twelve.cash
worked just sending sats from core lightning via zeus 🙂
CoinOS says unrecognized input, so looks like they cant do the twelve.cash thing
I don't think Alby can either.
That looks neater.
If you go to the link, then you can copy the long B12 address from there. Pretty neat.
Still new here but what is Bolt12 ?
What is Bolt12?
A Lightning address that doesn't change.
I’m confused. I see gitcitadel@geyser.fund… is that a bolt 12 lightning address?
I don’t understand bolt 12 at all, but i thought it was more of an invoice format?
No, that's a normal Lightning wallet. It Is intermediated by a server (like Alby or Geyser), so if the server goes down, so does your payment rail, even if your own node is up.
Bolt12 is the long string, in the profile text.
Some clients aren't showing my newest profile data, tho.
It's a lightning-native way of having a static payment address that allows a compatible node to reach out to your lightning node for an invoice, without the need for DNS, which is the current weakness of lightning addresses.
Sent a small on-chain donation - See it in a day or two 😅
Same. 😅
It's legit fun watching it tick tick tick along.
You should have it, now. 🥳
Arrived already. Let me zap you the difference between my pitiful on-chain transaction to you 🤣
Laeserin on-chain like
I actually have real money in that wallet. 😅
Lightning be like
🤣 - pity this transaction.
Awww, it's so cute. 😅
Added bolt12 to my profile again, but I never liked address re-use. I want to purple pill everyone who posts a bitcoin address on a website.🤣
We have seen, that the alternative is usually e-cash. Almost everyone moved from custodial Lightning to custodial e-cash. The hurdle of running a server is too high.
Bitcoin address or Bolt12 >> e-cash
Anyone worried about privacy could simply connect the addresses to a new npub, instead of the one they usually use. Nostr offers a layer of obfuscation _on top of_ the addresses.
What did I miss? 🤨
So far I could never find anyone to use or accept ‚ecash‘.
I already thought the whole thing is just an insider joke.
‚Almost everyone moved from custodial Lightning to custodial e-cash.‘
Where? Who? When? 
Good points, especially with low fees. I just tried silent link. I've never used it before. I'll try it out this weekend. Thanks.🤙
I have a BTC address as an i tag with three items in the array. I made a quick client to do it and it shows the profile donation address. I'm going to host the client so others can add theirs easily and I'll put a big banner on the site to ask clients to implement it.
Thank you, for working on this. 🥰
This is the most exciting thing to happen with online payments, on Nostr, for a good long while. I've been wondering how to add more payment rails to my profile.
nostr:npub1wqfzz2p880wq0tumuae9lfwyhs8uz35xd0kr34zrvrwyh3kvrzuskcqsyn can we support this in the profile data on #Alexandria ?
What are the details of the specification? 👀
I don't have anything concrete and I'm trying to work out it. I think I new tag should be used. Fetch my kind 0 and look at the raw.
It's taking too long to ask how I should do it. I'm about just say fuck it and make a new nip after I make an implementation and we can workshop it after.
I think a new "w" tag in the kind 0 with an array that looks like
["BTC:bitcoin:
], or [XMR:monero:],[
The "w" tag is an "Accepted Form of Payment"
You can have as many as you want as long as the network and asset are unique from each other.
Client can decide what to show.
Should define a few networks in the nip but it should be noted that clients can interpret the w tag however they want.
You could even deprecate ln address in the content of you did something like
w ,
BTC:lightning:
That's cool, and I like the design since it already establishes a way to express different payment methods apart from "native" ones like NIP-57 and NIP-60. However, there's definitely a privacy flaw for some wallets that shouldn't use static addresses, such as on-chain addresses, where reuse is not recommended.
I'm drafting something for markets and merchant payment preferences. We're using NIP-78 as a way to track xpub index. Also, for markets, we're writing a spec where we use a 'payment_preference' tag in the kind 0 event for the merchant to determine how they want to be paid for their services/products. The value of payment preferences can be lightning, cashu, or manual as an interactive/server-assisted method which is not Nostr-native
We all know we should rotate addresses for privacy reasons by now. But users should still have the option to have as many donation addresse as they want. I should be able to tell people where they can send me money, even if it isn't the best privacy policy. Privacy is my right to selectively reveal myself. If the user wants to reveal some aspects of how people pay them, that's their choice.
The nip will define a few different assets networks and addresses but the spec will be broadly left open and up to the client to interpret them ultimately.
Not to mention people could add liquid or monero addresses or always create new wallets for donations and they can rotate the address manually whenever they like.
Sure, but where do we solve the case for users who do not want to reveal themselves publicly in a place where you cannot control the reach of your publications? I think the only solution for the case of btc on-chain to keep privacy is to fallback to a server to provide a fresh btc address. Do you think this can be compatible with what you are trying to do? Like `["w", "bitcoin", "https://mypayserver..."]` ?
If you don't want to reveal yourself, then use a new wallet or don't post addresses publicly, especially addresses from a wallet that you've been using.
I want to reveal payment methods that I accept and people can find in order to payment. Even if you use a new wallet, it's very poor privacy. I totally agree there are going to be people wanting to set a static BTC address for some reason like donations. But I also think worth to explore how to offer also pro privacy options. Rn for example if you have a ln address you have to fetch an invoice from the server, I was talking about the same pattern here, but instead of receiving a bolt11 invoice you get a BTC address
I'm not saying the other options aren't necessary. They absolutely are. I'm just saying we should have both.
That's for sure 🤝
🤔 Interesting
Wdyt?
I had this idea, that it might be possible to generate new addresses on the fly, over Nostr relays or in the client , or something. Instead of a server. And the client would just show a different one, when called up. But I don't know enough, to know if that would work.
Hmm, I don't think there's any other way to do it for this case that isn't supported by a server responding or updating something when required, since there's no magic way to expose something, detect usage, and expose something new next time without requiring payer interactivity. At least for the xpub case where you want to generate a new address when someone uses the previous one. I was thinking sometime ago about "payment channels" and dh, so you can set up something more or less static that "changes" but with people you previously set up that dh. I mean you could calculate all shared secrets for all your contacts and assign a different xpub to each one. But it seems quite convoluted.
Don't you think a user should have the ability to specify multiple preferred payments? As a merchant, I would still like to accept Liquid, USDT or BTC lightning for instance.
I'll take anything I can sell for Bitcoin, to be honest.
But, I'd like to be able to say "Bitcoin on-chain or Lightning self-hosted preferred" because that saves me the conversion fees.
Absolutely. The `payment_preference` field is designed to express payment methods for "non-social" cases like zaps, tips/e-tips, where you want to specify how you prefer to receive payments for "the other stuff", services or goods you offer, in the case of a merchant. It's entirely valid to have multiple payment options, which we can implement using an array. For example:
`payment_preference: ["lightning", "manual"]`
This approach aligns well with your proposal of including wallets in tags. We can also introduce scopes, like this:
`payment_preference: ["lightning", "w:bitcoin", "w:usdt"]`
Alternatively, we could use just "w" to indicate all wallet details found in your profile as "w" tags. wdyt?
Right now it has the Asset, the network and the address in the array. I still need to add some checks to the inputs and maybe add the ability to remove them... But it'll be up tomorrow
I tried to zap that address from nostr:npub1h2qfjpnxau9k7ja9qkf50043xfpfy8j5v60xsqryef64y44puwnq28w8ch but I couldn’t figure out how. 😔
Yeah, it's not up to it.
Wait, I think I found out how to do it. Did you receive this?
Hey, cool! Yes, I got that!
It only worked with the offer code, not the human readable address.
Ah, the full Lightning address?
Yeah, this one:
lno1zrxq8pjw7qjlm68mtp7e3yvxee4y5xrgjhhyf2fxhlphpckrvevh50u0qf5se3npkealcue2te9dvrnre2ljf727cegxqdm7na95684l2wn8uqsr7umlffnk57t90nvss2mww4y5qaqmprd2cvharztce64ujhs4rlgqqv6fz88huw3xnert3zvf5734gne9nza7lu5r0a025sv2lugrhj8pepnly0rfdm85ssfehz0ha7gl874gkh5nq0nhh23lma88p4apys2tl2zfrjyf76ws3gtvlnv9h0e7hl0gx6jjjqqsxucaqre4hj2f4yagumy8kdz4av
🤙