-
Notifications
You must be signed in to change notification settings - Fork 526
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NIP-89 Ephemeral Bitcoin Transaction Package Relay #476
base: master
Are you sure you want to change the base?
Conversation
b77a747
to
290f722
Compare
this is awesome, I'll be able to retire https://psbt.io we'd need a tag like
|
good idea! Might be better to use network magic so we can delineate between signets as well. |
Nice work. JS Implementation: https://gist.github.com/melvincarvalho/70c29313554ce9d1a22ce9bf954909d9 |
Excellent work Ben! |
It may be worth pointing out that since every nostr account is a taproot address, this NIP allows the sending of on chain coins from any nostr account to any other, using only existing existing nostr infrastructure and potentially with increased privacy. It would then be a fairly simple task to look up utxos for a given nostr npub and build, for example, a wallet. |
If you add testnet and signet, it would be possible to build a web wallet and demo. |
Can you give it a sub-100 NIP number? |
This is great to see. EDIT: Removing other NIP draft and will re-submit. |
290f722
to
084aa6c
Compare
Changed to NIP-89 |
Updated to now include network magic so we can identify which network to broadcast to |
@ronaldstoner that looks like you are serving a different usecase, this is purely for broadcasting transactions, not constructing them. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea.
Also, no default please, let's require the tag instead.
Another idea: We could do this but with block headers, preventing eclipse attacks? 👀
I have updated the Republish Events by Peers (NIP-705) proposal to cover any ephemeral key events ( PR: #430 |
Sorry if being dumb, but I expected that the example content is a valid transaction. So I would expect that it has already been broadcast. However, I don't seem to find it. I did the following:
But there seems to be no transaction with this ID: https://mempool.space/tx/03bac0c86cae47f7813ec5841a53287c54eb43b3a153cce180b583c2b637f49d Am I doing something wrong? |
89.md
Outdated
Clients should generate an ephemeral keypair for each transaction they want to broadcast. This keypair should only ever | ||
be used for broadcasting that transaction. This is to best preserve the privacy of the user and to not link any extra | ||
metadata to the transaction. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if it's worth mentioning, but less is really more when it comes to broadcasting the transaction, especially if it's for privacy reasons.
If someone is doing this for privacy reasons, broadcasting to a lot of relays will maximize the chance to broadcast to a relay that is monitoring IPs and associating events with them. For now, it might not be the case that CA companies are running relays just to eavesdrop on bitcoin transactions being broadcasted, but over time there could be a bunch of events that are juicy from an bitcoin analysis perspective.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a section about it
@ekzyis you can't just hash it with segwit txs, also it is on testnet, this is the transaction https://mempool.space/testnet/tx/94f46759c50272034cfb00b944a8e5ef3bbff12c90b3f889acaf9bfa61c58969 |
8751187
to
df7938c
Compare
Added a section about recommendation around selecting relays. |
df7938c
to
8896929
Compare
Why mempool.space not local bitcoind node? Doing |
A rough version of this at https://github.com/monty888/txbroadcastr |
Plan to add that, was just hacking it together and didn't want to deal with having to add config options |
89.md
Outdated
@@ -32,6 +39,10 @@ For example: | |||
[ | |||
"magic", | |||
"0b110907" | |||
], | |||
[ | |||
"parent_txs", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why bother labeling these txes as parents and distinguishing them from the main transaction of this event? Can't you just as well do an array of transactions that are somehow related as suggested by @fiatjaf?
Also, a parent may have multiple children that only together contribute enough in fees to make mining the whole thing worthwhile?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I was overthinking this, simplified this much more to just be a list of transactions
b36b032
to
502a947
Compare
Okay sorry for all the little pushes, should be updated for package relay now |
What do you think about an update to the title (#476 (comment)) ?
|
I changed it to |
This is ready for re-review/merge |
I think this is great and I dream with the day in which the Bitcoin mempool will live on Nostr, but before merging I think we should wait to see it working in the real world first, just in case. Meanwhile this stays here reserved. |
Switched to hex encoded txs |
- mainnet: f9beb4d9 | ||
- testnet3: 0b110907 | ||
- signet (default): 0a03cf40 | ||
- regtest: fabfb5da |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it really a good idea to use these not very well-known magic hex codes here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be better to use network magic so we can delineate between signets as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right. But I suppose those alternative signets will also get their own name? Same as with the base64 vs hex for the txes, I think keeping this human readable is helpful in various situations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is better, this way we don't get any overlap, this could even be used for things like litecoin without needing new specifications.
I do agree just writing "mainnet" is more clear but I figured just enumerating them here would make it easy enough. Also, most bitcoin libraries will have these values available anyways.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think chances are low that it will ever come to the point where advantage can be taken of this.
|
||
- mainnet: f9beb4d9 | ||
- testnet3: 0b110907 | ||
- signet (default): 0a03cf40 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not make mainnet the default?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think since money is involved, I think it's good to be explicit when using mainnet.
Don't want someone send something on mainnet by accident. However, even addresses contain net information:
Invoice addresses on the Bitcoin Testnet are generated with a different prefix. See List of address prefixes and Testnet for more details.
-- https://en.bitcoin.it/wiki/Invoice_address#Testnet
But I think for signet and regtest this is not the case? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No objection to being explicit, but maybe then always be explicit? Signet doesn't look like such a natural choice for a default to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Signet is not meant to be the default, this is the magic bytes for the default signet. I see how that can be confusing, is there a better way to convey this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah maybe just signet
until an alternative signet rises and then update the NIP?
This conflicts with pre-existing PR #262 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a pre-existing PR for a NIP-89.
Please change this one.
|
||
- mainnet: f9beb4d9 | ||
- testnet3: 0b110907 | ||
- signet (default): 0a03cf40 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No defaults please.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh
Gentle bump on this. Did this ever move forward. I'm at the point where I could now build a whole wallet on top of nostr, nip-07 and a nostr based send like nip89 would be the final step. |
looks like nip 89 was taken, think that was all that was really needed |
Hacked together the transaction broadcaster real quick: https://github.com/benthecarman/nostr-tx-broadcast