Use Amount type for TxOut value field#1811
Conversation
|
Also the tests would need to be updated as well to use |
|
I inadvertently pressed ready for review on mobile and now I can't find how to revert, sorry |
|
Reverted back to draft. Concept ACK, I originally wanted to do this myself, happy to see I won't have to! :) |
bitcoin/src/blockdata/transaction.rs
Outdated
There was a problem hiding this comment.
Unrelated but looks like this should be an associated constant TxOut::NULL
There was a problem hiding this comment.
Agreed. And we probably shouldn't use default to construct it because it's actually a pretty obscure thing.
There was a problem hiding this comment.
Heads up that this is not yet addressed, but I'm going to merge this anyway since it's a pretty big PR that'll be hard to re-review.
There was a problem hiding this comment.
I don't think this can be made an associated constant because ScriptBuf::new() is not a const.
impl TxOut {
pub const NULL: Self = TxOut {
value: Amount::from_sat(0xffffffffffffffff),
script_pubkey: ScriptBuf::new() } }
}
..
}
Is there a reason this needs to be an associated const?
f987255 to
35eedb9
Compare
35eedb9 to
c8f2428
Compare
|
hmm almost ready. Looks like there are some changes for nightly and 1.48.0 needed still. |
|
Looks like it's not 1.48-related but serde-related. |
b49da67 to
2c4b8e8
Compare
|
I believe the CI failure is unrelated to this PR. Seems like cross rs can't find the docker container currently. |
|
Otherwise, this should be good to ship imo |
tcharding
left a comment
There was a problem hiding this comment.
ACK 2c4b8e82c45a499e12f774db7623f94ff0214f5d
bitcoin/src/crypto/sighash.rs
Outdated
There was a problem hiding this comment.
| /// use bitcoin::Amount; | |
| /// use bitcoin::{absolute, Transaction, Script}; | |
| /// use bitcoin::{absolute, Amount, Transaction, Script}; |
bitcoin/src/amount.rs
Outdated
There was a problem hiding this comment.
consensus_decode is inlined, might as well do this one too.
bitcoin/examples/taproot-psbt.rs
Outdated
There was a problem hiding this comment.
Recently @Kixunil made a push for using a custom integer format for bitcoin values 1_000_000_00, requires
#[allow(clippy::inconsistent_digit_grouping)] // Group to show 100,000,000 sats per bitcoin.
You can see a bunch of these in amount.rs. You could use it if you like it.
There was a problem hiding this comment.
I guess we should have Amount::from_whole_btc accepting u64. But also 50 * Amount::ONE_BTC should work.
There was a problem hiding this comment.
I tried both 50 * Amount::ONE_BTC and Amount::from_str("50 BTC").unwrap() here but it's not currently possible because this is a const so the compiler doesn't allow it.
There was a problem hiding this comment.
We should probably have #![allow(clippy::inconsistent_digit_grouping)] on the whole crate. This lint is stupid and has a 100% false positive rate for me.
There was a problem hiding this comment.
Also to avoid const issues we should have constants not only for 1 btc, but also 10, 25, 50, 100 and 21 million. And .1 and .01. Probably also 10, 100, 1000, 10000, 100000 sats (1_000_000 sats is already covered as .01 BTC).
These constants are all 1 LOC (plus a comment plus a whitespace) and will never change, so there's no harm in having a pile of them.
There was a problem hiding this comment.
@Kixunil in rust-bech32 we are panicking in a constfn; see discussion here rust-bitcoin/rust-bech32#103 (comment)
I think in 1.48 it's ok?
There was a problem hiding this comment.
Panicking is only const since 1.57.
There was a problem hiding this comment.
But we could conditionally use it to provide a better error message in higher versions.
Do we have examples of version conditionals already in the code base? It looks like things such as rustversion require an added dependency.
There was a problem hiding this comment.
@yancyribbens yep, grep the codebase for rust_v_1_53 to see how we've configured some things that show up only on Rust 1.53 and above.
2c4b8e8 to
104d206
Compare
|
Is there some considerations that need to made since this is a breaking API change? Downstream crates that use |
|
@yancyribbens unfortunately AFAICT there is no way to make this a "nice" breaking change. But FWIW I think it will get into the first pre-release as the only major thing, and the fix is nearly a search-and-replace operation, so I think it might be okay. |
tcharding
left a comment
There was a problem hiding this comment.
ACK 104d206bbb1fb1d778c956f4d313929b4f1d69cc
|
We are going to get merge conflicts if #1829 merges ahead of this. |
|
This will actually simplify tons of code that contain conversions between |
104d206 to
d57ec01
Compare
|
rebased to fix merge conflicts. |
9f7449b Use from_int_btc function for const context (yancy) f93e679 Add from_int_btc function to Amount (yancy) Pull request description: Followup PR from #1811 Added a `const` associated function `from_int_btc()` for Amount. `panic()` in const context is only available after 1.57+ so a work around is provided. ACKs for top commit: tcharding: ACK 9f7449b apoelstra: ACK 9f7449b Tree-SHA512: 7755234f2e573577d754f0224083cb7acc059e58833790fe344b0d9bad0acd89b0f74054d9efcba2133576222c7e9ab8dc3d81ddc10fbdcd4f83638d697118c4
Propose using
Amounttype for theTxOutvaluefield. I only implementedDecodableandEncodableenough to compile but this needs to completed obviously if usingAmountseems like a good idea.