Show Posts
|
Pages: [1]
|
Thank you nutildah! Getting such nice kudos on Bitcoin Talk is honestly a sweet milestone. These threads are feeling pretty legendary to me, especially the one I necro-posted to after a 10 year haitus.
|
|
|
I just necroposted to an old thread in which Johnson Lau came up with a numbering system for satoshis, which I independently also came up with a decade later. I think it's worth giving its own thread, so I'll copy what I posted here: So, funny story, in the beginning of 2022, I came up with the exact same scheme discussed in this thread. After I finished the scheme, I realized that it was basically serial numbers for satoshis, typed "satoshi serial numbers" into Google, and found this post. It feels natural extension to bitcoin, so it makes sense that multiple people have come up with it over the years. I called it "ordinal theory" or "ordinals", because it uses order in multiple places: - The order of satoshis in the supply of satoshis, for numbering
- The order of inputs and outputs of a transaction, for inheritance
- The order of transactions in a block, for inheritance of fees
I've spent the last year implementing it, so just 10 years after the OP, you can finally try it out! The binary, written in Rust, is called ord, and the code is on GitHub at https://github.com/casey/ord. I has a bunch of functionality: - Conversion between different, equivalent, notations, including the raw integer notation, block.offset notation, names, and degree notation, which is based on relation to difficulty adjustments and halvings.
- An index that connects to a Bitcoin Core node instance and tracks the location of all sats.
- An NFT implementation which embeds NFT content in Taproot witnesses, assigning them to the first sat of the first output of the transaction, "inscribing" that sat with content
- A rarity system: common = not the sat of the block, uncommon = first sat of the block, rare = first sat after a difficulty adjustment, epic = first sat after a halving, legendary = first sat after a conjunction, which is the difficulty adjustment and the halving happening on the same block, which happens every 6 halvings, and mythic = first sat of genesis block.
- A naming system, which assigns unique names consisting of the letters a through z to each sat, basically base 26, but starting backwards, so that all short names aren't locked in the genesis block.
- A block explorer, with a signet instance hosted at https://signet.ordinals.com and a mainnet instance at https://ordinals.com. The block explorer supports search, try putting in different representations for a sat: 0, 0.0, satoshi, etc.
- A wallet, which can construct transactions to send particular sats and make and send inscriptions.
Everything is open source, permissively licensed, and independently developed, so try it out and let me know what you think! Keep in mind that this is still very much alpha software. We're as careful as possible developing it, but it hasn't been audited and may have bugs
|
|
|
So, funny story, in the beginning of 2022, I came up with the exact same scheme discussed in this thread. After I finished the scheme, I realized that it was basically serial numbers for satoshis, typed "satoshi serial numbers" into Google, and found this post. It feels natural extension to bitcoin, so it makes sense that multiple people have come up with it over the years. I called it "ordinal theory" or "ordinals", because it uses order in multiple places: - The order of satoshis in the supply of satoshis, for numbering
- The order of inputs and outputs of a transaction, for inheritance
- The order of transactions in a block, for inheritance of fees
I've spent the last year implementing it, so just 10 years after the OP, you can finally try it out! The binary, written in Rust, is called ord, and the code is on GitHub at https://github.com/casey/ord. I has a bunch of functionality: - Conversion between different, equivalent, notations, including the raw integer notation, block.offset notation, names, and degree notation, which is based on relation to difficulty adjustments and halvings.
- An index that connects to a Bitcoin Core node instance and tracks the location of all sats.
- An NFT implementation which embeds NFT content in Taproot witnesses, assigning them to the first sat of the first output of the transaction, "inscribing" that sat with content
- A rarity system: common = not the sat of the block, uncommon = first sat of the block, rare = first sat after a difficulty adjustment, epic = first sat after a halving, legendary = first sat after a conjunction, which is the difficulty adjustment and the halving happening on the same block, which happens every 6 halvings, and mythic = first sat of genesis block.
- A naming system, which assigns unique names consisting of the letters a through z to each sat, basically base 26, but starting backwards, so that all short names aren't locked in the genesis block.
- A block explorer, with a signet instance hosted at https://signet.ordinals.com and a mainnet instance at https://ordinals.com. The block explorer supports search, try putting in different representations for a sat: 0, 0.0, satoshi, etc.
- A wallet, which can construct transactions to send particular sats and make and send inscriptions.
Everything is open source, permissively licensed, and independently developed, so try it out and let me know what you think! Keep in mind that this is still very much alpha software. We're as careful as possible developing it, but it hasn't been audited and may have bugs
|
|
|
I've been working on a project called Agora with a friend for a few months, and it's getting to be reasonably usable, so I wanted to announce it here. Agora is a simple web file server that can be configured to charge for downloads with Lightning Network payments. It is open source and self-hosted. I can be used to host and sell any kind of content, and integrates with LND to process payments. I can imagine a lot of different kinds of data shops that you could start with Agora. Media, research paper PDFs, standards documents, and more. It's a pre-MVP at the moment, but is still usable. We're busy adding new features, and hope to have an MVP release out soon. In the future, we hope to add support to make the browsing experience richer, for example with file previews and the ability to play movies and view PDFs directly in the browser. I you try it out, let us know how it works, and if there are any features you need! Some links: - Announcement Blog Post (Hosted by Agora!) - GitHub Repository- Twitter Announcement Thread
|
|
|
Updated the readme to make the challenge clearer.
|
|
|
Okay, to answer my own confused question: This is not a problem.
Transactions without any dust outputs, but with larger and smaller fees are still relayed over the network. Clients see those transactions that make it into the blockchain and adjust the definition of dust accordingly.
There is no chicken and egg problem because, in order to down-adjust the definition of dust, a client does not need to see a transaction with dusty outputs make it into the block chain. They merely need to see a tx with lower-than-average fees accepted into the blockchain. The force is undisturbed, and the satoshis flow freely.
|
|
|
Alright, one last one for the newbie ghetto. Gavin outlines here a plan to allow the network to dynamically adjust the minimum transaction fee by watching the transactions that are actually making it into blocks: https://github.com/bitcoin/bitcoin/pull/2577#issuecomment-17138244However, this raises a question. Were that to be implemented, imagine the following: Bitcoins are becoming more valuable, and the cost of computing resources is falling. Because of the above, miners are now willing to include transactions with lower fees in blocks. However, because the network as a whole isn't relaying any transactions which meet the new criteria (because they haven't seen any get into a block yet) the miners don't see them, and thus they continue not to see any included in a block. How would the network down-adjust the minimum transaction fee in this case?
|
|
|
It only does uppercase letters and numbers, but you could add a "." after a number that was intended to be lowercase.
|
|
|
I'm considering a site which would require taking a single transaction as input, and sending it to potentially hundreds or thousands of separate addresses in a single transaction.
Can someone help me figure out the amount, in tx fees, which would be needed for the network to confirm the transaction in a reasonable amount of time?
|
|
|
|