-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Implement burn #3437
base: master
Are you sure you want to change the base?
Implement burn #3437
Conversation
58c008e
to
61fcd70
Compare
61fcd70
to
7d4947e
Compare
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.
Finally having a look at this. There's just two things but they probably require a bit of refactoring. Especially the new command ord wallet burn
I think is important because burning is quite drastic and we want it to be a very distinct action.
@raphjaph thanks for the feedback, will get that done asap! |
@raphjaph just implemented the changes. Let me know if I can improve on anything else. Can also write some more tests if you have ideas for some good ones. |
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.
In OP_RETURNs there is no dust_limit and I see that you correctly disable the check for that. One thing you could try doing is only burn the exact sat that the inscription is on instead of the whole UTXO. This will require some careful changes to the TransactionBuilder
, which should then be tested as well in the unit tests of the transaction_builder.rs
file.
@raphjaph Do you think that's worth it? If I'm not mistaking doing so would add additional inputs to the transaction for extracting the sat. The fee for that could potentially be higher than what the inscription sats are worth. As an alternative idea: What if we exit the |
That's true, then let's just leave it how it is for now.
Sounds reasonble |
Cool, will adapt to that! |
ebf9b98
to
9666a4f
Compare
Let me know when this is ready for review :) |
@raphjaph Ready for review ✅ |
@raphjaph just saw you merged master? Was that on purpose? I can also just rebase if you like. |
@onchainguy-btc don't worry about rebasing, I'm going to squash merge this anyway. Gonna have a look at this today or tomorrow. The tests and linting also don't seem to pass yet. If you could fix, that would be great :) You can run our CI if you install |
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.
See comments above
In my last commit I also protected last postage from being burned. Not 100% sure if that makes sense though. |
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.
@onchainguy-btc This looks almost ready to go! I just made a couple small changes and also ran the fuzzing tests on the transaction builder.
Could you add some more tests:
- Multiple inscriptions in the same utxo and then try to burn and make sure it either fails or only burns the correct inscription.
- An inscription and a rune in the same utxo and then it should fail.
- Try
ord wallet burn <RUNE_ID>
and it should fail.
Co-authored-by: raph <[email protected]>
Co-authored-by: raph <[email protected]>
Co-authored-by: raph <[email protected]>
Co-authored-by: raph <[email protected]>
6c0ce1c
to
14e4472
Compare
@raphjaph just implemented the tests you requested ✅ |
After my first burn PR (#2766) got a bit outdated, I created a new one. Tried to make as less changes as possible. This PR does not support burn messages yet. Hope we can get the general burning merged first and then I'm happy to add support for an optional burn message via data pushes.