V12 Release
- Thread starter eduffield
- Start date
I believe there was no dust output - you can check your tx in blockchain explorer to make sure. I think it's just the actual size of the tx - it was slightly lower and wallet payed a smaller fee (note "~" next to Bytes and as a result next to Fee, After Fee and Change).Little bug that's been bugging me lately.
Using coin control, I sometimes make a payment amount so that it clears my dust. Sometime it works, more often it doesn't. I select whatever value plus the decimal values, but I end up with micro dust.
I've always wondered about the "~" .. I thought one of the premisses of the blockchain was to be able to be extremely precise in calculations, not a really really high percentage of accuracy.
Tried forcing the tx fee to the minimum (selecting the tick) - but it did not respect it. Let me try again just to be double sure I did it right;
EDIT: hmmm, yup, I think something may be up here.
Last edited by a moderator:
?
I'm not sure what you mean...
If you are curious why tx fee is 6700 duffs and not 6670 duffs as you would expect it from size calculations then that's is just how it works:
1. calculate tx size
2. calculate fee based on that size and add fee to tx (note: size could change here)
3. verify if it's still ok for this size and fee, if it's not - go to #1
So at the end it could be not exactly "fee/size = fee per kb" but still "~" instead.
If you were trying to calculate new fee/size that match fee per kb exactly you could end up in an endless loop.
Its the end of a long work week, so though this makes perfect sense, and I will review the math later.
My end-user question is the following;
I tick "pay minimum fee" of 0.00001 Dash. The tooltip says
But since such is not the case, given our blocks are far from full, why was I charged extra than the stipulated 0.00001 Dash?
.
Hmmm...
The fee is 0.00010000 per kb (that's what it is in code and that is what checkbox says as far as I see, not 0.00001000 as you put above).
The size is ~0.67 kb and you payed ~0.67 * 0.00010000 = ~0.00006700 and it looks all good for me.
UdjinM6 Was completely blind to the /kb 
So the checkbox above "total at least" - will also not guarantee the exact amount for a fee? I'm trying to figure out how either fixate a tx fee, or be able to determine before hand.
If I always use the same custom return address, would this help?
I'm thinking about nano-payments and how to account/predict the tx fee
So the checkbox above "total at least" - will also not guarantee the exact amount for a fee? I'm trying to figure out how either fixate a tx fee, or be able to determine before hand.
If I always use the same custom return address, would this help?
I'm thinking about nano-payments and how to account/predict the tx fee
The "cost" for the blockchain is the actual size of the transaction - the larger your tx the greater the "cost" (the fee). To account/predict tx fee you need to calculate the size of the raw tx. You can try to get into blockchain for free (there is a small cap for it) but keep in mind that there is no incentive for miners to include such txes so it might never be included in blocks at all.UdjinM6 Was completely blind to the /kb
So the checkbox above "total at least" - will also not guarantee the exact amount for a fee? I'm trying to figure out how either fixate a tx fee, or be able to determine before hand.
If I always use the same custom return address, would this help?
I'm thinking about nano-payments and how to account/predict the tx fee
This is where my tech knowledge of the blockchain starts to fail me. So what determines the size of a tx? Isn't it the sum of vins + vouts?
So if you create a feature to consolidate all your inputs after each tx through a persistent change address, every subsequent tx will have a much lower kb weight
Obviously this has other implications and not ideal for all, but just trying to figure this out.
.
The size of tx is the size of the raw data structure filled with your data, it has (almost) nothing to do with values. ("almost" - because different value could take different amount of memory/space to store them)
I would recommend to read more about txes:
https://bitcoin.org/en/developer-guide#transactions - to get the idea
https://bitcoin.org/en/developer-examples#transaction-tutorial - to see some real world examples
https://bitcoin.org/en/developer-reference#raw-transaction-format - to dive deeper into format
Having a persistent change address could help you to eliminate situations where you would have many inputs for some txes but it is highly not recommended use case because of the huge damage it brings to anonymity.
I have a masternode stuck at block 415399.
The debug.log is full of these messages:
Will -reindex fix this or is there another problem?
The debug.log is full of these messages:
Code:
2016-02-13 09:18:13 ProcessMessage(headers, 162003 bytes) FAILED peer=42
2016-02-13 09:18:13 ERROR: AcceptBlockHeader : block is marked invalid
2016-02-13 09:18:13 ERROR: invalid header received 0000000000056aa1260c0eeab2bf21da258e1a528ba6c9a20a739b70d7330af2
2016-02-13 09:18:13 ProcessMessage(headers, 162003 bytes) FAILED peer=5
2016-02-13 09:18:14 ERROR: AcceptBlockHeader : block is marked invalid
2016-02-13 09:18:14 ERROR: invalid header received 0000000000056aa1260c0eeab2bf21da258e1a528ba6c9a20a739b70d7330af2
2016-02-13 09:18:14 ProcessMessage(headers, 162003 bytes) FAILED peer=29
2016-02-13 09:18:15 ERROR: AcceptBlockHeader : block is marked invalid
2016-02-13 09:18:15 ERROR: invalid header received 0000000000056aa1260c0eeab2bf21da258e1a528ba6c9a20a739b70d7330af2
2016-02-13 09:18:15 ProcessMessage(headers, 162003 bytes) FAILED peer=8
2016-02-13 09:18:15 ERROR: AcceptBlockHeader : block is marked invalid
2016-02-13 09:18:15 ERROR: invalid header received 0000000000056aa1260c0eeab2bf21da258e1a528ba6c9a20a739b70d7330af2
2016-02-13 09:18:15 ProcessMessage(headers, 162003 bytes) FAILED peer=3
2016-02-13 09:18:20 ERROR: AcceptBlockHeader : block is marked invalid
2016-02-13 09:18:20 ERROR: invalid header received 0000000000056aa1260c0eeab2bf21da258e1a528ba6c9a20a739b70d7330af2
2016-02-13 09:18:20 ProcessMessage(headers, 162003 bytes) FAILED peer=6Will -reindex fix this or is there another problem?
flare
Well-known member
That worked like a charm! Thanks Flare!