docs: add amount example for units crate#43
docs: add amount example for units crate#43Zeegaths wants to merge 1 commit intorust-bitcoin:masterfrom
Conversation
cookbook/src/units/amount.md
Outdated
|
|
||
| **Setup** | ||
|
|
||
| If using `rust-bitcoin`, `Amount` is re-exported automatically: |
There was a problem hiding this comment.
In 1ede28e:
I'd drop the word "automatically" and maybe drop the prefix "re-".
|
Overall this looks amazing, thanks! I just commented a few nits. |
1ede28e to
e1c8a0c
Compare
Thanks for this! made the changes. I could pick up the rest of the docs? |
|
Thanks for the contribution.
I'll review quite heavily then so that it saves you time on the next ones. |
| @@ -0,0 +1,168 @@ | |||
| # Amount | |||
|
|
|||
| In this section, we will demonstrate different ways of working with Bitcoin amounts using the `Amount` type. The examples in this section will: | |||
There was a problem hiding this comment.
I think we should try to use little 'b' for the currency and big 'B' for the network.
| let zero = Amount::ZERO; | ||
| println!("Zero amount: {} satoshis", zero.to_sat()); | ||
|
|
||
| // No result handling for small amounts |
There was a problem hiding this comment.
| // No result handling for small amounts | |
| // No result handling for small amounts. |
| // Result handling for larger amounts | ||
| let large = Amount::from_sat(100_000_000).expect("valid amount"); | ||
| println!("Large Amount = {}", large); | ||
|
|
There was a problem hiding this comment.
Perhaps something like this is better?
// The amount constructor errors if input value is to large.
let large = Amount::from_sat(100_000_000).expect("valid amount");
println!("Large Amount = {}", large);
// Error free construction for amounts under approx 42 BTC ([u32::MAX]).
let small = Amount::from_sat_u32(50_000);
println!("Small Amount = {}", small);| let large = Amount::from_sat(100_000_000).expect("valid amount"); | ||
| println!("Large Amount = {}", large); | ||
|
|
||
| // Parsing string type to Amount - result handling needed for potential error |
There was a problem hiding this comment.
Everything that is code needs back ticks. Here Amount and a bunch of function names elsewhere.
| Amount::ONE_BTC.display_in(Denomination::Bitcoin).show_denomination() | ||
| ); | ||
| println!( | ||
| "Display in Satoshi with denomination: {}", |
There was a problem hiding this comment.
Lower case 's' for currency. Also I believe it should be pluralized 'Display in satoshis ...'
| println!("Display dynamic: {}", Amount::ONE_SAT.display_dynamic()); // shows in satoshis | ||
| println!("Display dynamic: {}", Amount::ONE_BTC.display_dynamic()); // shows in BTC | ||
|
|
||
| // to_string_in and to_string_with_denomination require alloc feature |
There was a problem hiding this comment.
| // to_string_in and to_string_with_denomination require alloc feature | |
| // `to_string_in` and `to_string_with_denomination` both require the `alloc` feature. |
| **Parsing and Formatting** | ||
|
|
||
| When parsing small amounts, result handling is not strictly necessary unless | ||
| you want extra caution. We use `.expect()` to handle results for larger amounts. |
There was a problem hiding this comment.
Did you use an LLM to create these docs or create them yourself?
| When formatting output, the preferred method is `.display_in()`. It can be | ||
| combined with `fmt::Formatter` options to precisely control zeros, padding, and | ||
| alignment — similar to how floats work in `core`, except that it's more precise, | ||
| meaning no rounding occurs. It also works without `alloc`, making it suitable for | ||
| `no_std` environments such as hardware wallets or embedded signing devices. |
There was a problem hiding this comment.
This sounds like LLM output to me and not super useful for a user who is coding at a level that they would read the cookbook.
| @@ -0,0 +1,21 @@ | |||
| Bitcoin is majorly expressed as BTC(bitcoins), mBTC(millibitcoins), sats(satoshis) or bits. | |||
There was a problem hiding this comment.
I'm not keen on this line. Because of the wording: 'majorly express in'. But I rekon better to just mention sats and BTC, but that could be subjective.
There was a problem hiding this comment.
I think "usually expressed in" is more idiomotic English.
BTW, these weird expressions make me think this is not LLM output. Though I agree that it often explains things that are too basic to be worth explaining.
| The BTC unit represents a 10^8 value so as to have sub-unit precision instead of large whole numbers. | ||
| This allows divisions of 1/10th, 1/100th and so on. |
There was a problem hiding this comment.
This whole sentence is a bit odd IMO.
|
|
||
| The satoshi, named after the original bitcoin creator, Satoshi Nakamoto, is the smallest unit of bitcoin currency representing a hundred millionth of one Bitcoin (0.00000001 BTC). | ||
|
|
||
| The Bitcoin source code uses satoshi to specify any Bitcoin amount and all amounts on the blockchain are denominated in satoshi before they get converted for display. |
There was a problem hiding this comment.
Are we documenting the protocol or the rust-bitcoin lib, its not obvious to me from some of these docs which direction we are going in?
There was a problem hiding this comment.
I kinda liked these two sentences. Yes, they're "off-topic" in that they're about the protocol rather than this library, but they're useful context for why we have such a weird and large API for Amount.
|
Sigh. Guess you were right @tcharding I wonder if it makes sense to move this repo to Forgejo....we hadn't really considered stopping hosting rust-bitcoin.org on Github. On the one hand, self-hosting a website is pretty-much the easiest thing we can do. On the other hand it's still kinda a PITA. |
Add cookbook entry for
Amountcovering the "Amount" section from #4694.What it covers:
MAX,ONE_BTC,ONE_SAT,ZERO,FIFTY_BTC)from_sat_u32andfrom_satparsedisplay_in,display_dynamic, and thealloc-gated string methodsNumOpResultusage with arithmetic and underflow handlingCloses the "Amount" section of #4694.