• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

V12 Release

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.

ny0JhbS.png


t15hzjI.png
 
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.

ny0JhbS.png


t15hzjI.png
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).
 
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).

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.

vXJElHo.png
 
Last edited by a moderator:
UdjinM6 let me know if I am missing something
?
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.
 
?
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

Paying the minimum fee is just fine as long as there is less transaction volume than space in the blocks.
But be aware that this can end up in a never confirming transaction once there is more demand for the Dash transaction than the network can process

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?

.
 
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 :oops:

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
 
UdjinM6 Was completely blind to the /kb :oops:

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.
 
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.

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.

.
 
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.
 
UdjinM6 Gotcha! Anonymity in this case would not be essencial. Anyway, thank you very much for taking the time to answer and the material to review!
 
I have a masternode stuck at block 415399.

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=6

Will -reindex fix this or is there another problem?
 
I have a masternode stuck at block 415399.

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=6

Will -reindex fix this or is there another problem?

Maybe this is worth a try first:

try "reconsiderblock 0000000000056aa1260c0eeab2bf21da258e1a528ba6c9a20a739b70d7330af2" from the console
 
Back
Top