-
Notifications
You must be signed in to change notification settings - Fork 39
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
Inscribe Krux #252
Comments
If this happens, it could mean that the Krux project officially supports the Ordinals thing and the use of the Bitcoin blockchain to store data. I wonder if people see this as more of a political act than a poetic one, and that could affect the image Krux has been building. Will we also support Ordinals transactions and the separation of uncommon sats? Many questions could be raised. |
Inscriptions disturbed my sleep for a few days when people started to flood the mempool, raise fees and inflate the UTXO set size. Maybe I was a FUD victim, but it's still not something I like. Now it's a reality off course we all must accept it. |
It's unfortunate that using Bitcoin to give people around the world a permanent, immutable, uncensorable place to download firmware for self-custody of it could be viewed negatively by proponents of Bitcoin. I don't know of a safer, more permanent place to store untampered downloads of Krux than Bitcoin itself. BitTorrent is a close second, but seeders need to have a copy and be online for others to download it. Also, and more importantly, they have no economic incentive to continue seeding Krux into the future, especially if it becomes "difficult" to do so. With inscriptions, you pay miners a fee to store the data, and the file will last forever. Sidestepping the arguments for and against ordinals and inscriptions as a whole, it's a fact that they exist right now... Therefore, in my mind, why not take advantage of them while they're here? Who knows... maybe Microsoft won't be so kind to continue hosting downloads of self-custody software in the future. |
Like you pointed out, there's always another way to share files across the internet... if M$ didn't like the project and remove from Github, we could use other alternatives like https://bountsr.org/nostr-based-github/ |
Indeed it is a reality we all must accept now whether we agree with it or not - I didn't agree with it at first. Since it is a reality, I think it would be a good idea to take advantage of it in the way that you proposed. I can see Bitcoiners getting behind using their full nodes for that. In case Microsoft does decide to do that, and also I think it would set our project apart from others. So coming from a marketing perspective, I think it's good. That being said this brings up a whole other discussion, which is where would the funds come from to do these occasional inscriptions? Correct me if I'm wrong, but I don't believe we've discussed $ yet. So since @odudex mentioned prioritizing funds, however they were raised, I would also be curious to see a comparison because maybe they could be used more efficiently in the meantime. I hope this comment helps, because after reading this thread, it seemed it needed another opinion (for others readers to compare to) and to bring up some questions so we can all come to an agreement/understanding in the end! Also it's not dev related, so this is one way I can tell myself I'm contributing...lol |
Bitcoin and every full node in the world storing the firmware that can be used for self-custody of it sounds poetic to me.
It just so happens that the Krux firmware binary is around 2MB which is small enough to fit into a block as an inscription.
However, due to the fees this would incur (~$500-$3000 per binary at current prices), it would likely be too cost prohibitive to inscribe every release.
Is there further compression we could do to drastically reduce the size of firmware?
If not, then perhaps it would suffice to do a special one-time inscription of each binary from the first Krux release that enables taproot support and has demonstrated itself to be stable after several months of usage.
Unfortunately, I can't do the inscribing and merely wanted to put this idea out into the wild.
EDIT: We could even publish future releases as much smaller patch (diff) files on top of prior releases, and provide a tool to assemble them after downloading the series of patches.
The text was updated successfully, but these errors were encountered: