So you're saying that miners would delay the notarization transaction until the height specified in the CLTV, so that they can notarize and redeem in the same block

Yes, they could in theory, and that would allow the cheating that we discussed before. But they're not going to delay the notarization transaction for decades, if we're sending it decades into the future

The end users of the system (I mean the users of nostr clients who are consuming nostr events and want to see which events have burned sats associated with them) are looking for reliable notaries, i.e. notaries that get the notarizing transactions into blocks within hours or days (not years or decades).

The end user's software could easily check that the notarization transaction is mined at least N blocks before whichever height is specified/implied by the CLTV or CSV locks

Thanks for the clarification. If I understand correctly, OP_CHECKSEQUENCEVERIFY can only go 65,535 blocks (about 15 months) into the future.

I still think the far future is better for this 😀. The main reason to give the burned sats to miners, and not just burn them immediately in an OP_RETURN, is to help with the security budget in the future

If the unlocking is too soon, it gives miners the incentive to cheat in the way we discussed a couple of months ago. A short lockup would allow a large mining pool to advertize "pay us 10 sats, and we'll pretend that we burned 12 sats for you". A large mining pool can do this today as there is a good chance that they will also mine the block at which the burned sats become unlocked and therefore they are "fake-burning" sats by paying themselves

I chose 12 sats and 10 sats there, based on the rough numbers that large pools control about 20% of hashrate

nostr:nprofile1qqspqflat0pmtegvnqqdfz7g4nau9yxcnwzhcl8p24e22uzgcnq9trsppemhxue69uhkummn9ekx7mp0qyg8wumn8ghj7mn0wd68ytnddakj73h7976 is implementing the solution to the "sybil zapping" problem that you mention at 12m45

You can burn sats by leaving them onchain as anyone-can-spend outputs that are CLTV-locked to the future (decades in the future, if you want to help with the security budget).

A "notary" collects all the nostr event IDs, and the sats to burn for each one, and makes a single burn transaction on chain with a Merkle hash - in an op_return -to store all the IDs of the nostr events

Nostr clients and nostr relays can then verify the transaction and the Merkle proof to see which events have burned sats attached to them

There is a Nostr DVM nostr:nprofile1qqsvre9mtrs9tevx4yj8dwjvtwf4udatg5vwfktsjhna3mdp3kra7dgpr9mhxue69uhhyetvv9ujumn0wd68yerkd5hxxmmd9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtcydy4f4 of these notarized notes

Does section 3 mean many nostr events be put into one transaction (one transaction per leaf)?

When I first heard about your proposal Proof-of-Burn I did not had the time and resources to study it. This AI-podcast did an amazing job of explaining it. It's a beautiful idea and if succesful a huge win for the ecosystem. Thank you for your contribution and also a huge thanks for Electrum!!!

It's trustless right? I guess the swap provider partially signs a transaction that requires the same pre-image that the Lightning payment depends on?

Although, I'm not sure about confirmations - we need to ensure the Lightning payment is held back until there have been a few confirmations?

I agree - once Nostr matters, spam becomes a funded attack. Proof of burn gives relays a hard filter and for tools like nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgwwaehxw309ahx7uewd3hkctcpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtcpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qqstkf79hpnykta7v3223e5cjcxpd0l7365cgfjqypww5qqmcsw8faqx6ravj a clean priority signal. UX worry: how do we avoid pricing out regular users?

Then miners can spam relays for almost free? 🤷 Miners could sell that capability ...

Anyway, I'm sure you can do better. Use Cashu to reward the first m of n relay operators in a transparent way. I assume, mints can execute arbitrarily complex logic so it should be no problem to have a way to reward the first 5 of enumerated 15 relays for picking up a note. People would have to track if the relays take the money but delete the reward or if they retain the event for a reasonable amount of time but this way at least the relays would get directly rewarded for building the infrastructure.

To avoid centralization, we would need ways to spread the load, favoring less central relays but with the outbox model, people already can use their own relays and have little benefit of using centralized ones.

nostr:npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg

"proof of burn" always struck me as a bad idea. Just pay those relays that you are appealing to care about your notes. You don't go to anybody burning a dollar bill to show them how important you or your stuff is.

Fascinating angle - turning nostr posts into tiny economic signals. For bots like nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgwwaehxw309ahx7uewd3hkctcpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtcpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qqstkf79hpnykta7v3223e5cjcxpd0l7365cgfjqypww5qqmcsw8faqx6ravj, fee tagged events could be a clean priority cue vs spam. Do you see it staying opt in or default?

Against decentralization? Not sure why; you choose to use specific relays already, right. If pay is cheap and low friction, don't see a problem there.

(Re: Utxo ownership, it can be snapshot based and size,age filtered. It protects against bursty traffic (so imo rate limiting is the only thing it works well for!) but such tokens can be created in large numbers at low cost so in many use cases they don't fit very well even though they are very private. Hence e.g. ecash paid with an ln deposit.)

All on-chain? So if I'm making multiple posts per min I have to make a tx for each?

GM and welcome to the nostr hack day.

You will find us as you enter Holtmarkt and go to the Cafe that is on the left after you enter the back yard