You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Pre-segwit miners used to evaluate tx fee and tx size. Txs were selected by their fee/byte.
Segwit brought the concept of "virtual size".
virtual size of a tx = tx serialized without witness data size + witness size (i.e. pub keys and signatures) / 4.
The virtual size of a legacy tx is the same as its size.
Segwit txs have similar sizes compared to legacy txs, but their virtual size is smaller.
New terms are now used such as vsize, vbyte, fee/vbyte, etc.
Miners now compare txs by its fee/vbyte (This is not entirely true, since they use tx weight, but we can do our math using fee/vbyte which is roughly equivalent)
See https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#additional-definitions for more info.
This PR does not include renaming size to vsize, feePerByte to feePerVbyte, etc.
I expect this PR won't be merged to master for quite some time.
The renames will introduce hundreds of changes all over the code, leading to merging hell.
I plan to do the renames either when merging date is closer or as an independent PR.
btw, the intention of this PR is not to refactor/improve the way fee calculation is done in bisq. It just pretends to take advantage of segwit fee reduction.
btw, the intention of this PR is not to refactor/improve the way fee calculation is done in bisq. It just pretends to take advantage of segwit fee reduction.
Is it planned to move to a bitcoinj native estimation model in a future PR?
btw, the intention of this PR is not to refactor/improve the way fee calculation is done in bisq. It just pretends to take advantage of segwit fee reduction.
Is it planned to move to a bitcoinj native estimation model in a future PR?
I have no plans to add any further code regarding fee estimation. What do you mean by "bitcoinj native estimation model"? Bisq uses bitcoinj fee estimation code and builds on top of it. Maybe you mean to use bicoinj 0.15's SendRequest.recipientsPayFees feature?. I think it would be great to rewrite bisq's fee estimation code, but I think it is out of scope for the segwit integration project.
I was referring to the fee estimation you implemented for BitcoinJ. I don't know any details about it, but I thought it was planned to use that in future.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
oscarguindzberg
force-pushed
the
fee-estimation
branch
from
Users reduce btc miner fees for segwit txs.
Pre-segwit miners used to evaluate tx fee and tx size. Txs were selected by their fee/byte.
Segwit brought the concept of "virtual size".
virtual size of a tx = tx serialized without witness data size + witness size (i.e. pub keys and signatures) / 4.
The virtual size of a legacy tx is the same as its size.
Segwit txs have similar sizes compared to legacy txs, but their virtual size is smaller.
New terms are now used such as vsize, vbyte, fee/vbyte, etc.
Miners now compare txs by its fee/vbyte (This is not entirely true, since they use tx weight, but we can do our math using fee/vbyte which is roughly equivalent)
See https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#additional-definitions for more info.
This PR does not include renaming size to vsize, feePerByte to feePerVbyte, etc.
I expect this PR won't be merged to master for quite some time.
The renames will introduce hundreds of changes all over the code, leading to merging hell.
I plan to do the renames either when merging date is closer or as an independent PR.
I suggest to use this link oscarguindzberg/bisq@segwit...oscarguindzberg:fee-estimation to understand the content of this PR until #4612 is merged. Otherwise you will find here the content for both PRs making understanding this PR more difficult