Conversation
4d4426f to
bb0275b
Compare
bb0275b to
679ad2e
Compare
|
BTW, I added this repository to my watch list, so if you ask something here, I should also see. |
72736d4 to
b149195
Compare
77f88e0 to
d07e713
Compare
Tibo-lg
left a comment
There was a problem hiding this comment.
I'm ok with using a struct though I'm not sure if it gives you more than a trait.
ce627d8 to
bd45a30
Compare
|
@Tibo-lg I think the only downside to using a Trait instead of a struct is the increased compile time. A monomorphised type has to be constructed at compile time, although the run-time should be the same, so either is probably fine. |
684474a to
54f01e7
Compare
4447ebd to
a4dd20f
Compare
684b498 to
0fcf9b9
Compare
d1c63d7 to
48fc157
Compare
|
I believe this PR is ready to merge. Any objections @Tibo-lg ? |
src/fee.rs
Outdated
|
|
||
| #[test] | ||
| fn get_effective_value() { | ||
| let fee_rate = 10; |
There was a problem hiding this comment.
If you are going with integers for the feerate, you could consider using ṩ/kvB as the base unit, since it allows you to be more precise than just full satoshi increments. That way you can create transactions with feerates at 1.103 ṩ/vB, instead of needing to pay 2 ṩ/vB if 1 ṩ/vB is insufficient for the priority you want to imbue the transaction with.
There was a problem hiding this comment.
I was also about to ask about how you avoid dust outputs, but then I saw the last commit. 👍
There was a problem hiding this comment.
If you are going with integers for the feerate, you could consider using ṩ/kvB as the base unit
Thanks, that's a good point. Wouldn't it be better to use a float for rate?
Otherwise, here would be:
let kv_bytes = weight / 4 /1024;
which means we lose a lot of precision with int division OR kvbytes is a float. It doesn't work to have kvbytes be a float and feerate as an int then.
There was a problem hiding this comment.
We don’t use “kibivirtualbytes”, but “kilovirtualbytes“:
1 MvB = 1000 kvB = 1 000 000 vB
We never use floats for consensus relevant calculations in Bitcoin Core to avoid any sort of rounding issues. YMMV.
There was a problem hiding this comment.
How about something like this: d1d38b1
/// Takes as input the fee_rate in $ per Kilovirtualbytes
/// and a size in Kilovirtualbytes and returns the fee amount.
///
/// * fee_rate: $ per kilovirtualbytes $KvB
/// * size: kilovirtualbytes KvB
/// * fee: $
There was a problem hiding this comment.
I just noticed this PR rust-bitcoin/rust-bitcoin#1627. Maybe it would be better to build off FeeRate as defined by Rust Bitcoin.
There was a problem hiding this comment.
How about something like this: d1d38b1
/// Takes as input the fee_rate in $ per Kilovirtualbytes /// and a size in Kilovirtualbytes and returns the fee amount. /// /// * fee_rate: $ per kilovirtualbytes $KvB /// * size: kilovirtualbytes KvB /// * fee: $
It’s not a dollar symbol but an “s” with a dot above and below: ṩ (u+1e69). The symbol for kilo is “k”, not “K”, the latter is the symbol for Kelvin, so it’s kvB, and that makes the feerate ṩ/kvB (which without the slash would be a multiplication rather than a division).
bca3356 to
882788c
Compare
|
Hey, this keeps popping up in my notifications but doesn’t seem to be ready for review. I’ll stop following notifications here for the time being. Please feel free to ping me here again when this PR is ready for review. |
Sorry for all the noise. I think it's about ready now, however there seems to be some unrelated failure with the nightly toolchain I'm trying to figure out. Anyway, I think at this point I'll just close this PR and open a fresh one once I figure out what's going on with CI. |
I have renamed and moved the random function to it's own module. This feature is similar to SRD in core. Also, I've added
effective_valuewhich is used for the sum calculation instead ofvalue. Lastly I did some minor refactoring so that the unit sizes used in the test match core.